Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #167206 > unrolled thread
| Started by | antispam@math.uni.wroc.pl |
|---|---|
| First post | 2022-08-25 02:33 +0000 |
| Last post | 2022-08-25 20:30 +0000 |
| Articles | 20 on this page of 236 — 17 participants |
Back to article view | Back to comp.lang.c
Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 02:33 +0000
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-25 03:00 +0000
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-26 00:22 +0000
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-26 16:48 +0000
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-25 03:01 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 14:29 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-25 08:10 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-08-25 16:23 +0000
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-25 20:53 +0200
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 06:56 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-26 17:29 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-26 13:44 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 13:56 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-26 16:01 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 10:27 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-28 03:52 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 15:05 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 17:00 -0700
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-29 15:16 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 09:38 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-30 04:03 -0700
Re: Are there any conformant C compilers? Anton Shepelev <anton.txt@gmail.com> - 2022-08-31 01:20 +0300
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 09:14 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 06:19 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 06:11 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 17:20 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 12:31 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 12:49 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-28 21:29 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 17:49 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 02:58 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 19:51 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-29 10:54 +0100
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-12 05:13 -0700
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 13:55 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 15:06 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 15:22 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 17:04 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:39 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-12 17:40 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 15:52 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 17:24 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 22:55 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-28 22:51 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 14:57 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 00:46 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 16:13 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 08:47 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:13 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-28 20:30 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 09:36 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 00:43 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 10:44 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 04:50 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 05:48 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 14:31 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:15 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 16:41 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 08:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:43 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 18:37 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 19:30 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 18:47 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 20:37 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 19:47 +0000
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 09:45 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 11:55 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-01 05:23 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 14:20 +0100
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-03 02:20 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-03 00:25 +0000
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-03 02:46 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 10:11 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 12:54 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 12:52 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 21:08 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 12:46 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 01:25 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-01 11:17 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 12:04 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-01 16:06 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 23:24 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 11:39 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 18:57 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-02 17:37 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 23:51 +0100
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 01:23 +0000
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 20:42 -0700
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 14:34 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-03 17:39 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 12:00 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 14:45 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 17:40 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 17:30 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-04 15:02 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-04 22:45 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 01:02 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 08:22 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 12:28 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 15:52 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 15:15 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-05 22:54 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 22:49 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 23:05 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 01:41 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 09:39 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 10:50 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 15:29 +0200
Re: Are there any conformant C compilers? Anton Shepelev <anton.txt@g{oogle}mail.com> - 2022-09-06 17:05 +0300
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 15:43 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-06 17:19 +0200
Re: Are there any conformant C compilers? tTh <tth@none.invalid> - 2022-09-06 18:19 +0200
Re: Are there any conformant C compilers? Öö Tiib <ootiib@hot.ee> - 2022-09-08 06:18 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-07 18:10 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-07 20:31 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-07 19:41 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-07 22:05 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-08 10:07 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 21:42 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-05 23:11 +0100
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 23:03 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-06 01:02 +0100
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-05 12:27 +0000
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-09-05 21:40 +0000
Re: Are there any conformant C compilers? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-09-05 14:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 20:24 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 22:30 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 00:19 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 12:35 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 14:17 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 15:20 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-04 15:58 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-04 18:00 +0100
Re: Are there any conformant C compilers? Manfred <noname@add.invalid> - 2022-09-04 19:26 +0200
Re: Are there any conformant C compilers? antispam@math.uni.wroc.pl - 2022-09-03 16:24 +0000
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-03 18:23 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-03 13:56 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 06:52 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:06 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 12:50 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:19 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-28 16:51 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 09:45 +0200
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 10:04 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-29 04:59 -0700
Re: Are there any conformant C compilers? Öö Tiib <ootiib@hot.ee> - 2022-08-29 07:32 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-29 16:47 +0200
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-29 17:51 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 13:15 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 14:58 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 15:54 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:17 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-30 18:34 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 11:25 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 14:14 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 15:28 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 15:02 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 15:28 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 17:06 +0200
Re: Are there any conformant C compilers? scott@slp53.sl.home (Scott Lurndal) - 2022-08-31 15:29 +0000
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 17:48 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-31 19:58 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-08-31 20:31 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 13:01 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-31 15:26 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-31 15:42 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 10:00 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-01 04:35 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-01 15:10 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 00:09 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 09:30 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 13:24 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 05:56 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 15:14 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 16:19 +0100
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 17:52 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 10:01 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 11:50 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 12:18 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 20:45 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 13:08 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 21:41 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 13:55 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 23:29 +0100
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-09-02 16:25 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 10:23 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-03 13:07 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-03 15:06 +0200
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 21:22 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-12 12:01 +0100
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:40 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-12 12:32 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-12 09:33 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-13 07:34 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-13 16:41 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-14 07:41 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-14 11:06 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 01:03 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-16 06:52 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-15 00:14 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-15 17:29 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-09-19 02:33 +0000
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-09-11 21:07 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 11:03 -0700
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-09-02 20:47 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 15:52 +0200
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-02 16:01 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-02 19:22 +0200
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-09-02 10:50 -0700
Re: Are there any conformant C compilers? Bart <bc@freeuk.com> - 2022-09-01 00:30 +0100
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-31 21:35 +0100
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-09-01 10:14 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 07:58 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 17:49 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:02 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 18:36 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 09:25 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 05:31 -0700
Re: Are there any conformant C compilers? David Brown <david.brown@hesbynett.no> - 2022-08-30 17:08 +0200
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 08:40 -0700
Re: Are there any conformant C compilers? Thiago Adams <thiago.adams@gmail.com> - 2022-08-30 08:50 -0700
Re: Are there any conformant C compilers? Opus <ifonly@youknew.org> - 2022-08-27 20:04 +0200
Re: Are there any conformant C compilers? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-08-25 17:03 +0100
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 09:50 -0700
Re: Are there any conformant C compilers? bart c <bart4858@gmail.com> - 2022-08-25 12:04 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 12:25 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-25 08:23 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-25 09:58 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 07:51 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 11:50 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-26 19:45 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-26 22:03 -0700
Re: Are there any conformant C compilers? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-08-27 08:14 -0700
Re: Are there any conformant C compilers? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-08-27 11:23 -0700
Re: Are there any conformant C compilers? "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-08-25 12:41 -0700
Re: Are there any conformant C compilers? Kaz Kylheku <480-992-1380@kylheku.com> - 2022-08-25 20:30 +0000
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2022-09-01 16:06 +0100 |
| Message-ID | <87ler3kuc5.fsf@bsb.me.uk> |
| In reply to | #167414 |
Bart <bc@freeuk.com> writes: > On 01/09/2022 11:17, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> > >>> This isn't about me. Very many people seem to run compilers like gcc >>> without all the right options. (Perhaps they rightly assume that it >>> knows how to do its job! That is, enforce the rules of the language, >>> without needing to be reminded of which ones the user needs >>> enforcing). >> My comments most certainly are about you. Your posts are not designed >> to help. In fact they make matters worse. Posting junk code without >> saying that it junk code misleads people learning C and does nothing to >> prompt compiler authors to change their default settings. >> Had you written something like: >> "C has const but most compilers are far too lax in their default modes >> letting obviously undefined code like this: >> <your code here> >> through on the nod." >> I would not have commented. > > Come on, no beginners read this group any more. They use forums like > Reddit. Do you post there? If so I hope you give lots of helpful tips about how to get the best from gcc. >>> Actually I /don't/ know to get gcc to report it properly. >> For your example, it's -Wcast-qual. It's not in the common sets of >> warnings because, I think, gcc takes the second view -- if you cast away >> const you must know what you are doing. Why, says gcc, would anyone >> write all those extra characters without wanting me to do it? > > But discarding swathes of code because the compiler thinks it's > pointless is fine? Again with the spin! Is the code pointless? If the compiler just /thinks/ it is then no, it's not fine. But if it correctly concludes that it's pointless, then sure. > (This makes benchmarking using gcc a nightmare.) I'm not an expert on benchmarking, but I have always seemed to manage. >>> And as I said, that still only warned. >> As you know perfectly well, you can choose to have such code fail with a >> hard error (-Werror), but most compilers take the view that putting in a >> cast like this indicates you really, really want to risk it. > > Sure. But then a lot of valid code will fail, because of things like: > > * Unused local variables (which may only be unused because some code > is temporarily commented out) Choose your warnings wisely. If you don't care about unused variables, either don't set -Wunused-variable or unset it with -Wno-unused-variable. You can even keep the warning and exclude it from being an error with -Wno-error=unused-variable. Similarly, you can just pick what warnings should be errors: -Werror=cast-qual. > * Defined but unused labels (very common with machine generated code) Ditto. > * Casts between object and function pointers Ditto. > It would be making most code impossibly strict. Indeed. gcc allows you to tailor the warnings are errors in exquisite detail. I am surprised that you don't have a my-gcc command (or an @opts file), already refined over the years to give you what you want. > A compiler needs to throw out OBVIOUSLY wrong and crazy programs > without having to be told, and without being forced to fix completely > harmless issues (see my spam example to DB just posted). Yes, but that a no true Scotsman argument. One person's crazy is another persons fix to get this device driver to actually work. Anyway, you have identified that /you/ want -Werror=cast-qual in your gcc settings. Work up a few more and you will see how helpful gcc can be. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-04 23:24 +0100 |
| Message-ID | <tf38jl$tvl$1@gioia.aioe.org> |
| In reply to | #167419 |
On 01/09/2022 16:06, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > Indeed. gcc allows you to tailor the warnings are errors in exquisite > detail. I am surprised that you don't have a my-gcc command (or an > @opts file), already refined over the years to give you what you want. > >> A compiler needs to throw out OBVIOUSLY wrong and crazy programs >> without having to be told, and without being forced to fix completely >> harmless issues (see my spam example to DB just posted). > > Yes, but that a no true Scotsman argument. One person's crazy is > another persons fix to get this device driver to actually work. Then you explicitly enable 'CRAZY' when necessary! You don't pass crazy code as a matter of course, on the off-chance that someone deliberately wants it, because it makes the vast majority of programs dangerously unsafe. > > Anyway, you have identified that /you/ want -Werror=cast-qual in your > gcc settings. Work up a few more and you will see how helpful gcc can > be. That's not gcc being helpful, it's a million programmers telling it how to do its effing job! (And creating a million private dialects in the process.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-08-31 11:39 -0700 |
| Message-ID | <87a67ki7fp.fsf@nosuchdomain.example.com> |
| In reply to | #167393 |
Bart <bc@freeuk.com> writes:
> On 31/08/2022 17:43, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> const int abc = 123;
>>> *(int*)&abc = 999;
>>>
>>> printf("abc = %d\n", abc);
>>>
>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>> read-only!
>> Don't you have a compiler that will tell you that such code is junk?
>> (It won't say so in so many words. Compiler writers are more polite
>> than I am!)
>
> Apparently not:
>
> c:\c>gcc c.c -oc.exe
> c:\c>c
> 999
>
> c:\c>tcc c.c
> c:\c>c
> 999
Compilers typically don't warn about pointer casts. A pointer cast
effectively tells the compiler "I know this isn't necessarily the right
type, but I know what I'm doing".
The code, of course, has undefined behavior. With optimization enabled,
on my system, the output is "123".
> With this one I do get a message:
>
> c:\c>bcc c
> Compiling c.c to c.exe
> In function main
> Type error: Modifying read-only var on line 6 c.c
>
> But that's most likely a compiler error or just non-conforming. If I
> pull out the stops with gcc, it gives me a warning, but I can still
> run the program.
The code does not violate a constraint. If bcc's message is a non-fatal
warning, there's no problem. If it's a fatal error, bcc could still be
conforming, since one of the allowed consequences of undefined behavior
is "... terminating a translation or execution (with the issuance of a
diagnostic message)". If bcc rejects the code when it can't prove that
it will always be executed, it might be non-conforming -- as most
C compilers are by default.
[...]
C has always allowed programmers to do silly things. Don't do that.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-08-31 18:57 +0200 |
| Message-ID | <teo3u4$1s2ik$1@dont-email.me> |
| In reply to | #167382 |
On 31/08/2022 17:41, Bart wrote:
> On 31/08/2022 15:15, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>
>>> On 31/08/2022 13:48, Thiago Adams wrote:
>>
>>>> That is a simple "named constant" or I prefer a "named
>>>> literal".(string literal, number, compound)
>>>
>>> This is what I've been advocating here for years. But people seem to
>>> prefer using a combination of #define, enum, const.
>>
>> At least you put in a "seem". It seems that way to you, but it seems to
>> me that people use what C has, and to extrapolate from that to what they
>> would prefer is step too far.
>
> The subthread is partly about the introduction of 'constexpr'. So
> finally an opportunity to add what C has long lacked, but instead it's
> taken one of C++'s hairy features and just cut it down.
>
>>> They especially seem keen on 'const', which is a read-only attribute
>>> for variables.
>>
>> And you have a problem with that?
>
> Yes. You don't get named constants by emulating them with read-only
> variables, that's just crass. And it lets you do this:
>
> const int abc = 123;
> *(int*)&abc = 999;
>
> printf("abc = %d\n", abc);
>
> It tells me that 'abc' is 999; so much for being a named constant, or
> read-only!
C does not "let you" do that. It specifically says the behaviour is
undefined in 6.7.3p6 :
"""
If an attempt is made to modify an object defined with a const-qualified
type through use of an lvalue with non-const-qualified type, the
behavior is undefined. If an attempt is made to refer to an object
defined with a volatile-qualified type through use of an lvalue with
non-volatile-qualified type, the behavior is undefined.
"""
For various reasons (such as compatibility with existing or external
code), it can be useful to be able to remove or add a "const" qualifier
to a pointer. You have to do that using an explicit cast - as you have
done here - which tells the compiler "I know what I am doing. I am a
responsible programmer and understand the consequences of my code". And
the compiler will trust the programmer. (Many compilers and linters
provide warnings on this sort of casting, but these will of course be
false positives on legitimate usage.)
Typically when running code like the sample above you will get a
segmentation fault or page fault of some kind when trying to write to
"abc" if it is defined at file scope. If it is defined at block scope
in a function, then the write will probably not fault (unless you are
using sanitizers of some sort). If it survives the write, then whether
your output will be 123 or 999 depends on the compiler, version, flags,
etc. It is all undefined behaviour.
So C "lets you do that" in the same way it lets you write :
int x = 10;
int y = 0;
int z = x / y;
Neither the language standards nor the compiler can stop you writing
something stupid - the best they can do is insist that you write it
awkwardly, such as with a cast.
>
> 'constexpr' seems just a way to continue using const variables, but
> allowing their values to be used as compile-time expressions.
>
That is part of it. But it also requires the constexpr object to have a
constant expression for its initialiser, which can be helpful to know.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-09-02 17:37 +0000 |
| Message-ID | <tetf0i$1rqd$1@gioia.aioe.org> |
| In reply to | #167382 |
Bart <bc@freeuk.com> wrote:
> On 31/08/2022 15:15, Ben Bacarisse wrote:
> > Bart <bc@freeuk.com> writes:
> >
> >> On 31/08/2022 13:48, Thiago Adams wrote:
> >
> >>> That is a simple "named constant" or I prefer a "named
> >>> literal".(string literal, number, compound)
> >>
> >> This is what I've been advocating here for years. But people seem to
> >> prefer using a combination of #define, enum, const.
> >
> > At least you put in a "seem". It seems that way to you, but it seems to
> > me that people use what C has, and to extrapolate from that to what they
> > would prefer is step too far.
>
> The subthread is partly about the introduction of 'constexpr'. So
> finally an opportunity to add what C has long lacked, but instead it's
> taken one of C++'s hairy features and just cut it down.
>
> >> They especially seem keen on 'const', which is a read-only attribute
> >> for variables.
> >
> > And you have a problem with that?
>
> Yes. You don't get named constants by emulating them with read-only
> variables, that's just crass. And it lets you do this:
>
> const int abc = 123;
> *(int*)&abc = 999;
>
> printf("abc = %d\n", abc);
>
> It tells me that 'abc' is 999; so much for being a named constant, or
> read-only!
Hmm, this is inclomplete. Completing it to:
const int abc = 123;
#include <stdio.h>
int main(void) {
*(int*)&abc = 999;
printf("abc = %d\n", abc);
return 0;
}
I get "Segmentation fault" trying to run it.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-02 23:51 +0100 |
| Message-ID | <teu1d9$1a4k$1@gioia.aioe.org> |
| In reply to | #167434 |
On 02/09/2022 18:37, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> On 31/08/2022 15:15, Ben Bacarisse wrote:
>>> Bart <bc@freeuk.com> writes:
>>>
>>>> On 31/08/2022 13:48, Thiago Adams wrote:
>>>
>>>>> That is a simple "named constant" or I prefer a "named
>>>>> literal".(string literal, number, compound)
>>>>
>>>> This is what I've been advocating here for years. But people seem to
>>>> prefer using a combination of #define, enum, const.
>>>
>>> At least you put in a "seem". It seems that way to you, but it seems to
>>> me that people use what C has, and to extrapolate from that to what they
>>> would prefer is step too far.
>>
>> The subthread is partly about the introduction of 'constexpr'. So
>> finally an opportunity to add what C has long lacked, but instead it's
>> taken one of C++'s hairy features and just cut it down.
>>
>>>> They especially seem keen on 'const', which is a read-only attribute
>>>> for variables.
>>>
>>> And you have a problem with that?
>>
>> Yes. You don't get named constants by emulating them with read-only
>> variables, that's just crass. And it lets you do this:
>>
>> const int abc = 123;
>> *(int*)&abc = 999;
>>
>> printf("abc = %d\n", abc);
>>
>> It tells me that 'abc' is 999; so much for being a named constant, or
>> read-only!
>
> Hmm, this is inclomplete. Completing it to:
>
> const int abc = 123;
>
> #include <stdio.h>
> int main(void) {
> *(int*)&abc = 999;
> printf("abc = %d\n", abc);
> return 0;
> }
>
> I get "Segmentation fault" trying to run it.
>
This all depends on matters outside the language itself.
I get 999 with tcc. I get a crash with gcc.
Moving abc inside the function, tcc still gives 999. gcc-O0 gives 999,
other optimisations give 123.
The crash happens if 123 ends up being up into write-protected memory
(so it doesn't get changed into 999, but it is still not satisfactory if
that crashes an application and people lose their work or there are
other consequences).
But consider that some processors don't have write-protected memory,
even if the compiler could make use of it.
The point all along is that if a simpler named-value feature was used,
all of the above becomes irrelevant. The program would fail to build in
all cases even with the crappiest compiler.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-09-03 01:23 +0000 |
| Message-ID | <teuaal$1ef$1@gioia.aioe.org> |
| In reply to | #167445 |
Bart <bc@freeuk.com> wrote:
> On 02/09/2022 18:37, antispam@math.uni.wroc.pl wrote:
> > Bart <bc@freeuk.com> wrote:
> >> On 31/08/2022 15:15, Ben Bacarisse wrote:
> >>> Bart <bc@freeuk.com> writes:
> >>>
> >>>> On 31/08/2022 13:48, Thiago Adams wrote:
> >>>
> >>>>> That is a simple "named constant" or I prefer a "named
> >>>>> literal".(string literal, number, compound)
> >>>>
> >>>> This is what I've been advocating here for years. But people seem to
> >>>> prefer using a combination of #define, enum, const.
> >>>
> >>> At least you put in a "seem". It seems that way to you, but it seems to
> >>> me that people use what C has, and to extrapolate from that to what they
> >>> would prefer is step too far.
> >>
> >> The subthread is partly about the introduction of 'constexpr'. So
> >> finally an opportunity to add what C has long lacked, but instead it's
> >> taken one of C++'s hairy features and just cut it down.
> >>
> >>>> They especially seem keen on 'const', which is a read-only attribute
> >>>> for variables.
> >>>
> >>> And you have a problem with that?
> >>
> >> Yes. You don't get named constants by emulating them with read-only
> >> variables, that's just crass. And it lets you do this:
> >>
> >> const int abc = 123;
> >> *(int*)&abc = 999;
> >>
> >> printf("abc = %d\n", abc);
> >>
> >> It tells me that 'abc' is 999; so much for being a named constant, or
> >> read-only!
> >
> > Hmm, this is inclomplete. Completing it to:
> >
> > const int abc = 123;
> >
> > #include <stdio.h>
> > int main(void) {
> > *(int*)&abc = 999;
> > printf("abc = %d\n", abc);
> > return 0;
> > }
> >
> > I get "Segmentation fault" trying to run it.
> >
>
> This all depends on matters outside the language itself.
>
> I get 999 with tcc. I get a crash with gcc.
>
> Moving abc inside the function, tcc still gives 999. gcc-O0 gives 999,
> other optimisations give 123.
Inside functions things are easier, you can use 'register' to make
it nonaddressable:
#include <stdio.h>
int main(void) {
register const int abc = 123;
*(int*)&abc = 999;
printf("abc = %d\n", abc);
return 0;
}
gcc still only produces a warning, but you get warning without
any extra options.
> The crash happens if 123 ends up being up into write-protected memory
> (so it doesn't get changed into 999, but it is still not satisfactory if
> that crashes an application and people lose their work or there are
> other consequences).
>
> But consider that some processors don't have write-protected memory,
> even if the compiler could make use of it.
>
> The point all along is that if a simpler named-value feature was used,
> all of the above becomes irrelevant. The program would fail to build in
> all cases even with the crappiest compiler.
Create language that can handle better _all_ current uses of
C, then after say 20 years it can replace C. But now we have
to leave with effects of past decisions. And those decisions
were not entirely bad: one was able to create relatively simple
compiler that generated resonably fast code. And one could use
C for quite many problems.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2022-09-02 20:42 -0700 |
| Message-ID | <87wnalkttc.fsf@nosuchdomain.example.com> |
| In reply to | #167450 |
antispam@math.uni.wroc.pl writes:
[...]
> #include <stdio.h>
> int main(void) {
> register const int abc = 123;
> *(int*)&abc = 999;
> printf("abc = %d\n", abc);
> return 0;
> }
>
> gcc still only produces a warning, but you get warning without
> any extra options.
That's odd, I get a fatal error by default with gcc 8.3.0 and 11.2.0.
c.c: In function ‘main’:
c.c:4:5: error: address of register variable ‘abc’ requested
4 | *(int*)&abc = 999;
| ^
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-09-03 14:34 +0000 |
| Message-ID | <tevomf$bmo$1@gioia.aioe.org> |
| In reply to | #167451 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> antispam@math.uni.wroc.pl writes:
> [...]
> > #include <stdio.h>
> > int main(void) {
> > register const int abc = 123;
> > *(int*)&abc = 999;
> > printf("abc = %d\n", abc);
> > return 0;
> > }
> >
> > gcc still only produces a warning, but you get warning without
> > any extra options.
>
> That's odd, I get a fatal error by default with gcc 8.3.0 and 11.2.0.
>
> c.c: In function ?main?:
> c.c:4:5: error: address of register variable ?abc? requested
> 4 | *(int*)&abc = 999;
> | ^
>
> [...]
My gcc is gcc 3.4.6. cc is gcc 6.3.0 and it gives error.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2022-09-03 17:39 +0000 |
| Message-ID | <CjMQK.158599$Ny99.102027@fx16.iad> |
| In reply to | #167459 |
antispam@math.uni.wroc.pl writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> antispam@math.uni.wroc.pl writes:
>> [...]
>> > #include <stdio.h>
>> > int main(void) {
>> > register const int abc = 123;
>> > *(int*)&abc = 999;
>> > printf("abc = %d\n", abc);
>> > return 0;
>> > }
>> >
>> > gcc still only produces a warning, but you get warning without
>> > any extra options.
>>
>> That's odd, I get a fatal error by default with gcc 8.3.0 and 11.2.0.
>>
>> c.c: In function ?main?:
>> c.c:4:5: error: address of register variable ?abc? requested
>> 4 | *(int*)&abc = 999;
>> | ^
>>
>> [...]
>
>My gcc is gcc 3.4.6. cc is gcc 6.3.0 and it gives error.
3.4.6 was released in 2006. It might be worth upgrading to a
slightly newer version (I've been using 9.3.0 lately, but we
have 12.2 available for testing).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-03 12:00 +0100 |
| Message-ID | <tevc3j$1cnm$1@gioia.aioe.org> |
| In reply to | #167450 |
On 03/09/2022 02:23, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> On 02/09/2022 18:37, antispam@math.uni.wroc.pl wrote:
>>> Bart <bc@freeuk.com> wrote:
>>>> On 31/08/2022 15:15, Ben Bacarisse wrote:
>>>>> Bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 31/08/2022 13:48, Thiago Adams wrote:
>>>>>
>>>>>>> That is a simple "named constant" or I prefer a "named
>>>>>>> literal".(string literal, number, compound)
>>>>>>
>>>>>> This is what I've been advocating here for years. But people seem to
>>>>>> prefer using a combination of #define, enum, const.
>>>>>
>>>>> At least you put in a "seem". It seems that way to you, but it seems to
>>>>> me that people use what C has, and to extrapolate from that to what they
>>>>> would prefer is step too far.
>>>>
>>>> The subthread is partly about the introduction of 'constexpr'. So
>>>> finally an opportunity to add what C has long lacked, but instead it's
>>>> taken one of C++'s hairy features and just cut it down.
>>>>
>>>>>> They especially seem keen on 'const', which is a read-only attribute
>>>>>> for variables.
>>>>>
>>>>> And you have a problem with that?
>>>>
>>>> Yes. You don't get named constants by emulating them with read-only
>>>> variables, that's just crass. And it lets you do this:
>>>>
>>>> const int abc = 123;
>>>> *(int*)&abc = 999;
>>>>
>>>> printf("abc = %d\n", abc);
>>>>
>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>> read-only!
>>>
>>> Hmm, this is inclomplete. Completing it to:
>>>
>>> const int abc = 123;
>>>
>>> #include <stdio.h>
>>> int main(void) {
>>> *(int*)&abc = 999;
>>> printf("abc = %d\n", abc);
>>> return 0;
>>> }
>>>
>>> I get "Segmentation fault" trying to run it.
>>>
>>
>> This all depends on matters outside the language itself.
>>
>> I get 999 with tcc. I get a crash with gcc.
>>
>> Moving abc inside the function, tcc still gives 999. gcc-O0 gives 999,
>> other optimisations give 123.
>
> Inside functions things are easier, you can use 'register' to make
> it nonaddressable:
>
> #include <stdio.h>
> int main(void) {
> register const int abc = 123;
But this is still going around the houses. It makes the declaration even
longer. It may potentially end up using a valuable register. It may end
up using a non-volatile register that must be saved during calls. There
may be a dozen such constants.
It will need a heavyweight optimising compiler to avoid some of those
disadvantages (and which will in turn take extra processing so longer
compile-times and extra power).
Compare with a feature like this:
constant abc = 123;
which has no such problems and can be handled by the simplest compiler.
But the arguments I'm hearing are, Ah, but what about more complex
objects, structs, arrays, compound literals, what about the one time in
1000 that taking the address might be conventient.
OK, so forget introducing such a simple feature, and stick with the (IMO
gross unsuitable) const and constexpr.
> *(int*)&abc = 999;
> printf("abc = %d\n", abc);
> return 0;
> }
>
> gcc still only produces a warning, but you get warning without
> any extra options.
>
>> The crash happens if 123 ends up being up into write-protected memory
>> (so it doesn't get changed into 999, but it is still not satisfactory if
>> that crashes an application and people lose their work or there are
>> other consequences).
>>
>> But consider that some processors don't have write-protected memory,
>> even if the compiler could make use of it.
>>
>> The point all along is that if a simpler named-value feature was used,
>> all of the above becomes irrelevant. The program would fail to build in
>> all cases even with the crappiest compiler.
>
> Create language that can handle better _all_ current uses of
> C, then after say 20 years it can replace C. But now we have
> to leave with effects of past decisions. And those decisions
> were not entirely bad: one was able to create relatively simple
> compiler that generated resonably fast code. And one could use
> C for quite many problems.
Introducing even a simple feature like 'constant' into standard C is a
big deal. But it seems to have happened with 'constexpr'; why not do the
other at the same time.
The actual implementation of 'constant' is not hard. Here it is an
action in C at file-scope:
constant int abc = 123;
#include <stdio.h>
int main(void) {
*(int*)&abc = 999;
printf("abc = %d\n", abc);
}
Compilation with bcc (other compilers won't recognise 'constant') shows:
Type error: Not lvalue: on line 5 c.c
I haven't got around to having a in-function version (it would take days
to get 'into' a C compiler enough to confidently make changes to
declarations), but here it is outside C:
proc main =
const abc = 123
int def := 456
...
This will simply not allow assignment to 'abc' nor allow & to be
applied. But compare with the normal variable declaration that follows:
that uses ":=" which does a runtime assignment or initialisaton. The
named constant uses "=" which denotes a compile-time identity.
It is this clear division between the concepts that is missing in C and
causes so much confusion.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-03 14:45 +0100 |
| Message-ID | <tevlqf$17ae$1@gioia.aioe.org> |
| In reply to | #167454 |
On 03/09/2022 12:00, Bart wrote:
> On 03/09/2022 02:23, antispam@math.uni.wroc.pl wrote:
>> Bart <bc@freeuk.com> wrote:
>>> On 02/09/2022 18:37, antispam@math.uni.wroc.pl wrote:
>>>> Bart <bc@freeuk.com> wrote:
>>>>> On 31/08/2022 15:15, Ben Bacarisse wrote:
>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>
>>>>>>> On 31/08/2022 13:48, Thiago Adams wrote:
>>>>>>
>>>>>>>> That is a simple "named constant" or I prefer a "named
>>>>>>>> literal".(string literal, number, compound)
>>>>>>>
>>>>>>> This is what I've been advocating here for years. But people seem to
>>>>>>> prefer using a combination of #define, enum, const.
>>>>>>
>>>>>> At least you put in a "seem". It seems that way to you, but it
>>>>>> seems to
>>>>>> me that people use what C has, and to extrapolate from that to
>>>>>> what they
>>>>>> would prefer is step too far.
>>>>>
>>>>> The subthread is partly about the introduction of 'constexpr'. So
>>>>> finally an opportunity to add what C has long lacked, but instead it's
>>>>> taken one of C++'s hairy features and just cut it down.
>>>>>
>>>>>>> They especially seem keen on 'const', which is a read-only attribute
>>>>>>> for variables.
>>>>>>
>>>>>> And you have a problem with that?
>>>>>
>>>>> Yes. You don't get named constants by emulating them with read-only
>>>>> variables, that's just crass. And it lets you do this:
>>>>>
>>>>> const int abc = 123;
>>>>> *(int*)&abc = 999;
>>>>>
>>>>> printf("abc = %d\n", abc);
>>>>>
>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>> read-only!
>>>>
>>>> Hmm, this is inclomplete. Completing it to:
>>>>
>>>> const int abc = 123;
>>>>
>>>> #include <stdio.h>
>>>> int main(void) {
>>>> *(int*)&abc = 999;
>>>> printf("abc = %d\n", abc);
>>>> return 0;
>>>> }
>>>>
>>>> I get "Segmentation fault" trying to run it.
>>>>
>>>
>>> This all depends on matters outside the language itself.
>>>
>>> I get 999 with tcc. I get a crash with gcc.
>>>
>>> Moving abc inside the function, tcc still gives 999. gcc-O0 gives 999,
>>> other optimisations give 123.
>>
>> Inside functions things are easier, you can use 'register' to make
>> it nonaddressable:
>>
>> #include <stdio.h>
>> int main(void) {
>> register const int abc = 123;
>
> But this is still going around the houses. It makes the declaration even
> longer. It may potentially end up using a valuable register. It may end
> up using a non-volatile register that must be saved during calls. There
> may be a dozen such constants.
From a comment of David Brown, and your [antispam's] own remark,
'register' may no longer literally mean to use a register, but is used
as an attribute to inhibit using &.
But ... this doesn't really change anything. It's just going to a lot of
trouble to avoid implementing a very simple feature; take your pick from:
#define abc 123 # unscoped
enum {abc = 123}; # int32 only (but in C23?)
register const int abc = 123; # functions only (plus urgh..)
const int abc = 123; # Not compile-time const
constexpr int = 123; # Can use &
All with their own limitations, a few of which are highlighted.
The lack of a direct feature has been discussed in the past, but since C
didn't have it, all you could do was complain.
But now that a new feature /has/ been approved, it still hasn't got it.
Just a new twist on an already poor existing one.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-03 17:40 +0200 |
| Message-ID | <tevsgu$2toci$1@dont-email.me> |
| In reply to | #167458 |
On 03/09/2022 15:45, Bart wrote:
> On 03/09/2022 12:00, Bart wrote:
>> On 03/09/2022 02:23, antispam@math.uni.wroc.pl wrote:
>>> Bart <bc@freeuk.com> wrote:
>>>> On 02/09/2022 18:37, antispam@math.uni.wroc.pl wrote:
>>>>> Bart <bc@freeuk.com> wrote:
>>>>>> On 31/08/2022 15:15, Ben Bacarisse wrote:
>>>>>>> Bart <bc@freeuk.com> writes:
>>>>>>>
>>>>>>>> On 31/08/2022 13:48, Thiago Adams wrote:
>>>>>>>
>>>>>>>>> That is a simple "named constant" or I prefer a "named
>>>>>>>>> literal".(string literal, number, compound)
>>>>>>>>
>>>>>>>> This is what I've been advocating here for years. But people
>>>>>>>> seem to
>>>>>>>> prefer using a combination of #define, enum, const.
>>>>>>>
>>>>>>> At least you put in a "seem". It seems that way to you, but it
>>>>>>> seems to
>>>>>>> me that people use what C has, and to extrapolate from that to
>>>>>>> what they
>>>>>>> would prefer is step too far.
>>>>>>
>>>>>> The subthread is partly about the introduction of 'constexpr'. So
>>>>>> finally an opportunity to add what C has long lacked, but instead
>>>>>> it's
>>>>>> taken one of C++'s hairy features and just cut it down.
>>>>>>
>>>>>>>> They especially seem keen on 'const', which is a read-only
>>>>>>>> attribute
>>>>>>>> for variables.
>>>>>>>
>>>>>>> And you have a problem with that?
>>>>>>
>>>>>> Yes. You don't get named constants by emulating them with read-only
>>>>>> variables, that's just crass. And it lets you do this:
>>>>>>
>>>>>> const int abc = 123;
>>>>>> *(int*)&abc = 999;
>>>>>>
>>>>>> printf("abc = %d\n", abc);
>>>>>>
>>>>>> It tells me that 'abc' is 999; so much for being a named constant, or
>>>>>> read-only!
>>>>>
>>>>> Hmm, this is inclomplete. Completing it to:
>>>>>
>>>>> const int abc = 123;
>>>>>
>>>>> #include <stdio.h>
>>>>> int main(void) {
>>>>> *(int*)&abc = 999;
>>>>> printf("abc = %d\n", abc);
>>>>> return 0;
>>>>> }
>>>>>
>>>>> I get "Segmentation fault" trying to run it.
>>>>>
>>>>
>>>> This all depends on matters outside the language itself.
>>>>
>>>> I get 999 with tcc. I get a crash with gcc.
>>>>
>>>> Moving abc inside the function, tcc still gives 999. gcc-O0 gives 999,
>>>> other optimisations give 123.
>>>
>>> Inside functions things are easier, you can use 'register' to make
>>> it nonaddressable:
>>>
>>> #include <stdio.h>
>>> int main(void) {
>>> register const int abc = 123;
>>
>> But this is still going around the houses. It makes the declaration
>> even longer. It may potentially end up using a valuable register. It
>> may end up using a non-volatile register that must be saved during
>> calls. There may be a dozen such constants.
>
> From a comment of David Brown, and your [antispam's] own remark,
> 'register' may no longer literally mean to use a register, but is used
> as an attribute to inhibit using &.
Of course, "used" is a strong word here - the "register" keyword is
almost unknown in modern C programming. It has already been deprecated
in C++, where it had the same meaning, and no one really noticed.
If there are some compilers that have the kind of problems you worry
about with register variables taking up processor registers, it really
doesn't matter. Such compilers might be good for teaching, research,
fun, or when you want a very small or very fast tool - but no one cares
about them when they are interested in generating fast object code.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-03 17:30 +0100 |
| Message-ID | <tevveo$198i$1@gioia.aioe.org> |
| In reply to | #167460 |
On 03/09/2022 16:40, David Brown wrote: > On 03/09/2022 15:45, Bart wrote: >> From a comment of David Brown, and your [antispam's] own remark, >> 'register' may no longer literally mean to use a register, but is used >> as an attribute to inhibit using &. > > Of course, "used" is a strong word here - the "register" keyword is > almost unknown in modern C programming. It has already been deprecated > in C++, where it had the same meaning, and no one really noticed. > > If there are some compilers that have the kind of problems you worry > about with register variables taking up processor registers, it really > doesn't matter. Such compilers might be good for teaching, research, > fun, or when you want a very small or very fast tool - but no one cares > about them when they are interested in generating fast object code. You seem very deprecating of such things (of course, you usually get someone else to write your compilers for you!). I'm thinking of introducing such a feature myself although it will more be of a hint that a variable will be heavily used. (It'll be separate from the declaration; it can be used for globals; and is an experiment to see how worthwhile it might be). If you don't think much of such annotations in a programming language, consider that Python has introduced type annotations. They can be ignored by an implementation, or can be used to generate more efficient code. Of course, being Python, that makes it alright. No suggestion that such an approach to speeding up a language makes it a toy.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-04 15:02 +0200 |
| Message-ID | <tf27lp$381gu$1@dont-email.me> |
| In reply to | #167462 |
On 03/09/2022 18:30, Bart wrote: > On 03/09/2022 16:40, David Brown wrote: >> On 03/09/2022 15:45, Bart wrote: > >>> From a comment of David Brown, and your [antispam's] own remark, >>> 'register' may no longer literally mean to use a register, but is >>> used as an attribute to inhibit using &. >> >> Of course, "used" is a strong word here - the "register" keyword is >> almost unknown in modern C programming. It has already been >> deprecated in C++, where it had the same meaning, and no one really >> noticed. >> >> If there are some compilers that have the kind of problems you worry >> about with register variables taking up processor registers, it really >> doesn't matter. Such compilers might be good for teaching, research, >> fun, or when you want a very small or very fast tool - but no one >> cares about them when they are interested in generating fast object code. > > You seem very deprecating of such things (of course, you usually get > someone else to write your compilers for you!). > Strange - I thought I listed quite a few reasons why one might have, want or use a compiler that doesn't do much in the way of optimisation. One thing you can be sure of, however, is that anyone seriously interested in the speed and efficiency of generated code is going to use a compiler that can generate optimised code - and thus the limitations you worry about would not apply. > I'm thinking of introducing such a feature myself although it will more > be of a hint that a variable will be heavily used. (It'll be separate > from the declaration; it can be used for globals; and is an experiment > to see how worthwhile it might be). > > If you don't think much of such annotations in a programming language, > consider that Python has introduced type annotations. They can be > ignored by an implementation, or can be used to generate more efficient > code. > Useful annotations are useful. The Python type annotations are primarily about checking correctness of code, which is much harder when types are dynamic. When you want fast Python implementations you ideally use JIT compilation implementations (like PyPy), which infer the types as they go along. Some annotations in some languages do, of course, aid efficient code generation. Modern (and by "modern" here I mean "mainstream for about 30 years") compiler techniques have made "register" in C totally redundant as an efficiency hint, along with "inline". If a compiler does not have good lifetime analysis and register allocation schemes (and I appreciate that this are difficult algorithms, and not necessarily the focus for a particular compiler) then manual source code hints might be useful. But compilers that cannot handle register allocation on their own are not going to be used when you want fast code. > Of course, being Python, that makes it alright. No suggestion that such > an approach to speeding up a language makes it a toy. Python type annotations are not about speed. And Python is a completely different kind of language from C.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2022-09-04 22:45 +0000 |
| Message-ID | <tf39q6$1997$1@gioia.aioe.org> |
| In reply to | #167462 |
Bart <bc@freeuk.com> wrote:
> On 03/09/2022 16:40, David Brown wrote:
> > On 03/09/2022 15:45, Bart wrote:
>
> >> ?From a comment of David Brown, and your [antispam's] own remark,
> >> 'register' may no longer literally mean to use a register, but is used
> >> as an attribute to inhibit using &.
> >
> > Of course, "used" is a strong word here - the "register" keyword is
> > almost unknown in modern C programming.? It has already been deprecated
> > in C++, where it had the same meaning, and no one really noticed.
> >
> > If there are some compilers that have the kind of problems you worry
> > about with register variables taking up processor registers, it really
> > doesn't matter.? Such compilers might be good for teaching, research,
> > fun, or when you want a very small or very fast tool - but no one cares
> > about them when they are interested in generating fast object code.
>
> You seem very deprecating of such things (of course, you usually get
> someone else to write your compilers for you!).
>
> I'm thinking of introducing such a feature myself although it will more
> be of a hint that a variable will be heavily used. (It'll be separate
> from the declaration; it can be used for globals; and is an experiment
> to see how worthwhile it might be).
There is _very_ simple register allocation method that is likely to
do better than looking at 'register' to do register allocation.
I am working now on compiler backend that is uing moral equivalent
on 'register' declaration: first N variables are allocated in
registers. And I see that this leads to much worse quality
than otherwise possible. Namely, bunch of registers are
reserverd for temporaries and unavailable to normal variables.
Since number of temporary registers is limited and there is
no real allocater intermediate results are frequently forced
to memory. They are reloaded from memory even if a copy is
available in a register. So computation suffers due to
lack of temporary registers (and smart management of register).
OTOH there are cases when work could be done just on variables,
so temporary registers are almost unused, but some variables
end in memory due to fact that registers are reserved for
temporaries.
Let me put it differenty: main issue is allocation for temporaries.
'register' variables may help a bit if author allocates
crucial temporaries to variables and re-uses them when
free. I would not count on normal user doing this in
useful way. Of course, you know about compilation so
you may be able to do better job of "register allocation by
hand". Still, getting real register allocator seem to be
better solution.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-05 01:02 +0100 |
| Message-ID | <tf3eb2$h8c$1@gioia.aioe.org> |
| In reply to | #167483 |
On 04/09/2022 23:45, antispam@math.uni.wroc.pl wrote:
> Bart <bc@freeuk.com> wrote:
>> On 03/09/2022 16:40, David Brown wrote:
>>> On 03/09/2022 15:45, Bart wrote:
>>
>>>> ?From a comment of David Brown, and your [antispam's] own remark,
>>>> 'register' may no longer literally mean to use a register, but is used
>>>> as an attribute to inhibit using &.
>>>
>>> Of course, "used" is a strong word here - the "register" keyword is
>>> almost unknown in modern C programming.? It has already been deprecated
>>> in C++, where it had the same meaning, and no one really noticed.
>>>
>>> If there are some compilers that have the kind of problems you worry
>>> about with register variables taking up processor registers, it really
>>> doesn't matter.? Such compilers might be good for teaching, research,
>>> fun, or when you want a very small or very fast tool - but no one cares
>>> about them when they are interested in generating fast object code.
>>
>> You seem very deprecating of such things (of course, you usually get
>> someone else to write your compilers for you!).
>>
>> I'm thinking of introducing such a feature myself although it will more
>> be of a hint that a variable will be heavily used. (It'll be separate
>> from the declaration; it can be used for globals; and is an experiment
>> to see how worthwhile it might be).
>
> There is _very_ simple register allocation method that is likely to
> do better than looking at 'register' to do register allocation.
> I am working now on compiler backend that is uing moral equivalent
> on 'register' declaration: first N variables are allocated in
> registers. And I see that this leads to much worse quality
> than otherwise possible. Namely, bunch of registers are
> reserverd for temporaries and unavailable to normal variables.
> Since number of temporary registers is limited and there is
> no real allocater intermediate results are frequently forced
> to memory. They are reloaded from memory even if a copy is
> available in a register. So computation suffers due to
> lack of temporary registers (and smart management of register).
> OTOH there are cases when work could be done just on variables,
> so temporary registers are almost unused, but some variables
> end in memory due to fact that registers are reserved for
> temporaries.
>
> Let me put it differenty: main issue is allocation for temporaries.
> 'register' variables may help a bit if author allocates
> crucial temporaries to variables and re-uses them when
> free. I would not count on normal user doing this in
> useful way. Of course, you know about compilation so
> you may be able to do better job of "register allocation by
> hand". Still, getting real register allocator seem to be
> better solution.
>
I tried such a simple register allocator a couple of years ago, which
just kept some locals in registers when there were spare registers.
When applied to typical benchmarks, it worked pretty well.
On real applications, it made a lot less difference, especially when I
switched machines (from older Intel to newer AMD), then often it made no
measurable difference.
So I'm looking at not bothering with optimisation at all. This is
because the difference between gcc-O3 (ver. 10.x), and my unoptimised
code is not that much for my programs anyway.
Typically mine will be half the speed of gcc -O3 (gcc code takes 50%
less runtime). Here gcc takes 33% less runtime than mine:
c:\cx>tm ccgcc sql -c
Compiling sql.c to sql.obj
TM: 0.27
c:\cx>tm cc sql -c
Compiling sql.c to sql.obj
TM: 0.40 (0.38 when optimised!)
The application is 'cc', my C compiler. ccgcc.exe was created with gcc
-O3 via a C rendering, cc.exe is my unoptimised code, and the task is
compiling a 250Kloc application (a lot bigger than typical input). (Tcc
here takes 0.46 seconds.)
I will still do some experiments to see if keeping globals in registers
makes a worthwhile difference.
One problem is that I have to know and explicitly annotate specific
bottlenecks (that one I can probably semi-automate).
But another is that some programs don't have obvious bottlenecks,
control-flow is too spread out.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-05 08:22 +0200 |
| Message-ID | <tf44in$3ghic$1@dont-email.me> |
| In reply to | #167484 |
On 05/09/2022 02:02, Bart wrote: > > I tried such a simple register allocator a couple of years ago, which > just kept some locals in registers when there were spare registers. > > When applied to typical benchmarks, it worked pretty well. > > On real applications, it made a lot less difference, especially when I > switched machines (from older Intel to newer AMD), then often it made no > measurable difference. > > So I'm looking at not bothering with optimisation at all. This is > because the difference between gcc-O3 (ver. 10.x), and my unoptimised > code is not that much for my programs anyway. > > Typically mine will be half the speed of gcc -O3 (gcc code takes 50% > less runtime). Here gcc takes 33% less runtime than mine: > At the higher end, people pay several times as much for chips that are less than 33% faster. Of course speed does not always matter, but sometimes it does. You are also lucky you are still working on plain x86, and not targeting ARM or other architectures, or even SIMD on x86. Modern x86 implementations excel at handling poor code quickly, because there is so much poor quality code around for these devices. That means you can get away with a much simpler compiler and still have fast end results.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2022-09-05 12:28 +0100 |
| Message-ID | <tf4mg1$ghu$1@gioia.aioe.org> |
| In reply to | #167486 |
On 05/09/2022 07:22, David Brown wrote: > On 05/09/2022 02:02, Bart wrote: >> >> I tried such a simple register allocator a couple of years ago, which >> just kept some locals in registers when there were spare registers. >> >> When applied to typical benchmarks, it worked pretty well. >> >> On real applications, it made a lot less difference, especially when I >> switched machines (from older Intel to newer AMD), then often it made >> no measurable difference. >> >> So I'm looking at not bothering with optimisation at all. This is >> because the difference between gcc-O3 (ver. 10.x), and my unoptimised >> code is not that much for my programs anyway. >> >> Typically mine will be half the speed of gcc -O3 (gcc code takes 50% >> less runtime). Here gcc takes 33% less runtime than mine: >> > > At the higher end, people pay several times as much for chips that are > less than 33% faster. Of course speed does not always matter, but > sometimes it does. Actually 33% less runtime means 50% faster. But remember that scripting languages are also tremendously popular, which can be 1-2 /magnitudes/ slower than optimised C code. So even a C compiler such as Tiny C can be significantly faster than such languages for implementing the same programs. (In fact, Tiny C compiling itself still results in a compiler that runs rings around most others. I thought it was due to its using gcc -O3, but that's only part of it. Here: https://github.com/sal55/langs/blob/master/Compilertest3.md tcc variations occupy all four entries at the end of the first table, the fast end.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2022-09-05 15:52 +0200 |
| Message-ID | <tf4uu9$3jer7$1@dont-email.me> |
| In reply to | #167487 |
On 05/09/2022 13:28, Bart wrote: > On 05/09/2022 07:22, David Brown wrote: >> On 05/09/2022 02:02, Bart wrote: >>> >>> I tried such a simple register allocator a couple of years ago, which >>> just kept some locals in registers when there were spare registers. >>> >>> When applied to typical benchmarks, it worked pretty well. >>> >>> On real applications, it made a lot less difference, especially when >>> I switched machines (from older Intel to newer AMD), then often it >>> made no measurable difference. >>> >>> So I'm looking at not bothering with optimisation at all. This is >>> because the difference between gcc-O3 (ver. 10.x), and my unoptimised >>> code is not that much for my programs anyway. >>> >>> Typically mine will be half the speed of gcc -O3 (gcc code takes 50% >>> less runtime). Here gcc takes 33% less runtime than mine: >>> >> >> At the higher end, people pay several times as much for chips that are >> less than 33% faster. Of course speed does not always matter, but >> sometimes it does. > > Actually 33% less runtime means 50% faster. > > But remember that scripting languages are also tremendously popular, > which can be 1-2 /magnitudes/ slower than optimised C code. As I said, speed does not always matter. > > So even a C compiler such as Tiny C can be significantly faster than > such languages for implementing the same programs. No one (well, no one who knows what they are doing) uses small C compilers when they want high speed results. That does not mean that everyone who uses or needs C is concerned about getting the fastest results. But those who /do/ want the fastest results, use one of the mainstream optimising compilers. > > (In fact, Tiny C compiling itself still results in a compiler that runs > rings around most others. I thought it was due to its using gcc -O3, but > that's only part of it. Here: > > https://github.com/sal55/langs/blob/master/Compilertest3.md > > tcc variations occupy all four entries at the end of the first table, > the fast end.) You seem to be having trouble understanding the information on that page. It shows that tcc /compiles/ quickly - not that it generates efficient code. I know you are fanatically obsessed with the speed of compilers, so maybe tcc is the perfect compiler for /you/. That's fine - I'm glad you are happy. Most serious C programmers look for other features and trade-offs in the tools.
[toc] | [prev] | [next] | [standalone]
Page 5 of 12 — ← Prev page 1 … 3 4 [5] 6 7 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web