Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch > #117702 > unrolled thread
| Started by | jgd@cix.co.uk (John Dallman) |
|---|---|
| First post | 2026-08-31 17:35 +0100 |
| Last post | 2026-09-07 17:15 -0700 |
| Articles | 20 on this page of 475 — 30 participants |
Back to article view | Back to comp.arch
Styles of addressing jgd@cix.co.uk (John Dallman) - 2026-08-31 17:35 +0100
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-08-31 17:35 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-08-31 17:48 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-08-31 17:43 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-08-31 22:20 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-01 16:10 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-01 18:01 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 11:55 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 19:58 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 17:07 -0700
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 01:06 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-08 08:28 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-08 13:31 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 00:19 +0000
Re: Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-09 18:21 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 18:41 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 20:42 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 21:45 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 21:49 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 23:28 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 03:45 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:57 +0000
Re: Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-23 22:08 -0400
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:24 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-02 01:31 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 02:44 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-02 07:45 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-31 22:32 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 00:12 +0000
Re: Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-01 05:24 +0000
Re: 370 address sizes, Styles of addressing John Levine <johnl@taugh.com> - 2026-09-01 16:05 +0000
Re: 370 address sizes, Styles of addressing Andy Valencia <vandys@vsta.org> - 2026-09-01 10:07 -0700
Re: 370 address sizes, Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-01 21:17 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-02 18:59 -0400
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 01:50 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-09 16:30 -0400
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-09 20:50 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 23:25 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:53 +0000
Re: 370 address sizes, Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 16:36 +0000
Re: 370 address sizes, Styles of addressing Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 08:46 -0700
Re: 370 address sizes, Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-16 17:21 +0000
Re: 370 address sizes, Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-16 10:58 -0700
Re: 370 address sizes, Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 10:00 +0000
Re: 370 address sizes, Styles of addressing John Levine <johnl@taugh.com> - 2026-09-17 20:37 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 18:15 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-16 18:59 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-16 19:16 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:19 +0000
Re: 370 address sizes, Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-16 12:24 -0700
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:20 +0000
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 17:12 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 17:26 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 18:27 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 20:29 -0400
Re: 370 address sizes, Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-16 18:03 -0400
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-03 02:46 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-05 04:26 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 14:40 +0000
Re: 370 address sizes, Styles of addressing jgd@cix.co.uk (John Dallman) - 2026-09-03 20:53 +0100
Re: 370 address sizes, Styles of addressing quadibloc@invalid.com (John Savard) - 2026-09-03 15:48 +0000
Re: 370 address sizes, Styles of addressing David Schultz <david.schultz@earthlink.net> - 2026-09-03 12:07 -0500
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 17:33 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 20:23 +0000
Re: 370 address sizes, Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-03 16:44 -0400
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 17:32 +0000
Re: 370 address sizes, Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-03 14:43 -0400
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-03 20:32 +0000
Re: 370 address sizes, Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-03 21:08 +0000
Re: 370 address sizes, Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-04 01:11 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-05 01:08 +0000
Re: Styles of addressing mas@a4.home - 2026-09-06 03:56 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-06 13:51 +0000
Re: Styles of addressing kegs@provalid.com (Kent Dickey) - 2026-09-10 04:11 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 14:59 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-10 15:16 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 16:06 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 16:55 +0000
Re: Styles of addressing Robert Finch <robfi680@gmail.com> - 2026-09-10 21:43 -0400
Re: Styles of addressing kegs@provalid.com (Kent Dickey) - 2026-09-13 17:50 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-14 00:42 +0000
CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:02 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-10 18:58 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-10 19:01 +0000
Re: CHERI Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-10 22:45 +0200
Re: CHERI Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-11 16:49 -0400
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:00 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 17:50 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 18:14 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 21:59 +0000
Re: CHERI (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-11 22:34 +0000
Data-independent timing (was: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 06:22 +0000
Re: Data-independent timing (was: CHERI Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-14 10:04 -0700
Re: Data-independent timing (was: CHERI scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 18:08 +0000
Re: Data-independent timing (was: CHERI anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 21:35 +0000
Re: CHERI (was: Styles of addressing) jgd@cix.co.uk (John Dallman) - 2026-09-12 11:31 +0100
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 16:42 +0000
Re: CHERI (was: Styles of addressing) Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-11 07:01 +0000
Re: CHERI (was: Styles of addressing) kegs@provalid.com (Kent Dickey) - 2026-09-13 17:21 +0000
Re: CHERI (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 18:00 +0000
Re: CHERI (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 06:35 +0000
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-06 10:44 -0400
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 14:56 +0000
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-06 12:58 -0400
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-06 12:04 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:59 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-07 04:29 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-07 10:40 +0200
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 18:25 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-07 23:10 +0200
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 21:58 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 05:30 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-08 11:20 +0200
Re: Styles of addressing Paul Clayton <paaronclayton@gmail.com> - 2026-09-09 12:23 -0400
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 03:47 +0000
Re: Styles of addressing Josh Vanderhoof <x@y.z> - 2026-09-07 18:22 -0400
Re: Styles of addressing EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-07 13:28 -0400
Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 18:33 +0000
Re: Addressing Shared Stuff scott@slp53.sl.home (Scott Lurndal) - 2026-09-08 15:48 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-08 20:05 +0000
Re: Addressing Shared Stuff Paul Clayton <paaronclayton@gmail.com> - 2026-09-13 12:05 -0400
Re: Addressing Shared Stuff jgd@cix.co.uk (John Dallman) - 2026-09-16 23:11 +0100
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 00:26 +0000
Re: Addressing Shared Stuff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 09:32 +0000
Re: Addressing Shared Stuff jgd@cix.co.uk (John Dallman) - 2026-09-17 13:32 +0100
Re: Addressing Shared Stuff Michael S <already5chosen@yahoo.com> - 2026-09-18 01:08 +0300
Re: Addressing Shared Stuff anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-18 06:10 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 16:06 +0000
Re: Addressing Shared Stuff scott@slp53.sl.home (Scott Lurndal) - 2026-09-17 17:26 +0000
Re: Addressing Shared Stuff MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 19:40 +0000
Re: Addressing Shared Stuff Andy Valencia <vandys@vsta.org> - 2026-09-14 12:52 -0700
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-06 20:25 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 00:02 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-07 00:09 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-07 06:17 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 23:46 +0000
Re: Styles of addressing Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-09-06 20:21 +0300
Re: Styles of addressing antispam@fricas.org (Waldek Hebisch) - 2026-09-08 15:08 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-08 20:11 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-09 00:35 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-09 08:19 +0200
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-09 10:58 +0000
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-10 06:16 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:22 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-10 22:42 +0200
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:32 +0000
Re: Styles of addressing George Neuner <gneuner2@comcast.net> - 2026-09-10 17:02 -0400
Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 06:33 +0000
Re: Optimization by programmers (was: Styles of addressing) Thomas Koenig <tkoenig@netcologne.de> - 2026-09-11 08:55 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 17:54 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-11 23:19 +0200
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-11 22:05 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-12 09:30 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-12 13:23 +0200
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-12 13:18 +0200
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-12 17:09 +0000
Re: Optimization by programmers (was: Styles of addressing) George Neuner <gneuner2@comcast.net> - 2026-09-11 23:25 -0400
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 08:38 +0000
Re: Optimization by programmers (was: Styles of addressing) Thomas Koenig <tkoenig@netcologne.de> - 2026-09-12 09:09 +0000
Re: Optimization by programmers (was: Styles of addressing) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 09:17 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-14 16:24 +0200
Re: Optimization by programmers (was: Styles of addressing) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:34 -0700
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-12 17:15 +0000
Re: Optimization by programmers (was: Styles of addressing) jgd@cix.co.uk (John Dallman) - 2026-09-12 19:13 +0100
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 18:14 +0000
Re: Optimization by programmers (was: Styles of addressing) quadibloc@invalid.com (John Savard) - 2026-09-13 03:28 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-13 14:27 +0000
Re: Optimization by programmers (was: Styles of addressing) John Levine <johnl@taugh.com> - 2026-09-13 14:58 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-13 16:09 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 17:38 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-13 17:34 +0000
Re: Optimization by programmers (was: Styles of addressing) scott@slp53.sl.home (Scott Lurndal) - 2026-09-14 14:43 +0000
Re: Optimization by programmers (was: Styles of addressing) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-14 15:44 +0000
Re: Optimization by programmers (was: Styles of addressing) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-14 18:01 +0000
Re: Optimization by programmers Paul Clayton <paaronclayton@gmail.com> - 2026-09-16 13:14 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 16:47 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-17 19:38 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-17 21:25 +0000
Re: Optimization by programmers Paul Clayton <paaronclayton@gmail.com> - 2026-09-21 22:10 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-18 16:38 -0400
Re: Optimization by programmers David LaRue <huey.dll@tampabay.rr.com> - 2026-09-19 06:01 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-19 06:25 +0000
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-20 02:56 -0400
Re: Optimization by programmers John Levine <johnl@taugh.com> - 2026-09-20 20:12 +0000
Microarchitectural effects on performance (was: Optimization ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 06:55 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-21 17:04 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-23 05:39 +0000
Re: Microarchitectural effects on performance (was: Optimization ...) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-23 18:34 +0000
Re: Microarchitectural effects on performance Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-23 13:53 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-21 12:48 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 17:17 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-21 20:06 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-21 23:48 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-22 05:25 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-22 14:13 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-26 07:44 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-09-22 14:48 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 19:28 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-22 05:19 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-22 08:29 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 05:40 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 06:45 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-22 14:32 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-22 15:21 -0700
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-23 05:23 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-23 14:01 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 16:52 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 08:01 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 10:38 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 07:54 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 18:24 +0200
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-23 11:20 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 21:24 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-02 04:10 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-02 10:05 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-02 22:04 -0700
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-03 13:13 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-24 11:56 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-24 16:35 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-23 07:47 -0700
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-24 07:59 -0700
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-24 09:29 -0700
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-25 07:27 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 17:12 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-27 11:51 -0700
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-25 11:16 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 19:00 +0200
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 18:12 +0000
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-26 10:25 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-27 13:42 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 18:18 +0300
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-27 18:04 +0200
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 19:43 +0300
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-27 10:55 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-27 22:12 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-28 02:59 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-28 14:43 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 07:14 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 11:36 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-05 16:48 +0300
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-06 23:16 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 13:28 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 16:43 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 19:57 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 22:31 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 21:28 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-11 08:41 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-11 18:14 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-11 20:56 +0200
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 07:47 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-12 11:25 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 16:20 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-12 17:10 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-12 21:05 +0200
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 12:03 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-13 10:27 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 20:00 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-14 08:02 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-14 08:50 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-14 23:39 +0200
Re: Optimization by programmers Andy Valencia <vandys@vsta.org> - 2026-10-13 09:09 -0700
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-13 16:31 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-10-13 18:12 +0000
Re: Optimization by programmers Niklas Holsti <niklas.holsti@tidorum.invalid> - 2026-10-13 20:02 +0300
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-13 19:50 +0200
Comment delimiters (was: Optimization by programmers) Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-13 23:24 -0400
Re: Comment delimiters David Brown <david.brown@hesbynett.no> - 2026-10-14 09:56 +0200
Re: Comment delimiters (was: Optimization by programmers) George Neuner <gneuner2@comcast.net> - 2026-10-14 12:14 -0400
Re: Comment delimiters (was: Optimization by programmers) quadibloc@invalid.com (John Savard) - 2026-10-14 18:07 +0000
Re: Comment delimiters (was: Optimization by programmers) Thomas Koenig <tkoenig@netcologne.de> - 2026-10-14 18:50 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-14 15:45 -0400
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-15 06:17 +0000
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-16 06:35 +0000
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-16 17:10 +0000
Re: Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-16 18:55 +0000
Re: Comment delimiters George Neuner <gneuner2@comcast.net> - 2026-10-16 18:57 -0400
Re: Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 04:01 +0000
Re: Comment delimiters Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-15 15:42 -0400
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-16 12:46 -0400
Re: Comment delimiters anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-16 17:56 +0000
Re: FORTRAN, was Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 03:56 +0000
Re: FORTRAN, was Comment delimiters Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-17 11:09 -0400
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-17 10:06 -0400
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-17 14:58 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-18 10:55 -0400
Re: Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-18 17:56 +0000
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-19 18:09 +0000
Re: more Fortran, Comment delimiters John Levine <johnl@taugh.com> - 2026-10-20 03:50 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-20 20:53 +0100
Re: more Fortran, Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-20 20:15 +0000
Re: more Fortran, Comment delimiters scott@slp53.sl.home (Scott Lurndal) - 2026-10-20 20:44 +0000
Re: more Fortran, Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-20 22:49 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-21 23:06 +0100
Re: more Fortran, Comment delimiters scott@slp53.sl.home (Scott Lurndal) - 2026-10-22 00:02 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-22 23:43 +0100
Re: more Fortran, Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-23 00:27 +0000
Re: more Fortran, Comment delimiters Bill Findlay <findlaybill@blueyonder.co.uk> - 2026-10-23 03:46 +0100
Re: more Fortran, Comment delimiters Michael S <already5chosen@yahoo.com> - 2026-10-23 11:21 +0300
Re: more Fortran, Comment delimiters David Brown <david.brown@hesbynett.no> - 2026-10-23 12:49 +0200
Re: Algol, was more Fortran, Comment delimiters John Levine <johnl@taugh.com> - 2026-10-21 03:28 +0000
Re: Algol, was more Fortran, Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-21 14:10 +0000
Re: Algol, was more Fortran, Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:11 +0000
Re: Algol, was more Fortran, Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-21 20:38 +0000
Re: Comment delimiters EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-17 10:06 -0400
Re: Comment delimiters Thomas Koenig <tkoenig@netcologne.de> - 2026-10-16 20:35 +0000
Re: FORTRAN, was Comment delimiters John Levine <johnl@taugh.com> - 2026-10-17 03:49 +0000
Re: FORTRAN, was Comment delimiters MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-17 17:16 +0000
Re: FORTRAN, was Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-18 02:03 +0000
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-17 08:51 +0000
Re: Comment delimiters Robert Finch <robfi680@gmail.com> - 2026-10-18 22:54 -0400
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-19 08:39 +0000
Re: Comment delimiters quadibloc@invalid.com (John Savard) - 2026-10-19 08:42 +0000
Re: Comment delimiters cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-20 01:43 +0000
Re: Comment delimiters (was: Optimization by programmers) MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-14 22:43 +0000
Re: Comment delimiters (was: Optimization by programmers) quadibloc@invalid.com (John Savard) - 2026-10-15 18:15 +0000
Re: Optimization by programmers quadibloc@invalid.com (John Savard) - 2026-10-12 16:12 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 18:40 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 19:21 +0000
Re: Optimization by programmers John Levine <johnl@taugh.com> - 2026-10-12 19:54 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 21:10 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 22:37 +0000
Re: smashing constants, sort of like Optimization by programmers John Levine <johnl@taugh.com> - 2026-10-13 00:35 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-13 18:40 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 15:47 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 15:41 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 18:37 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 21:07 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-10-12 22:35 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-17 02:03 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-10-07 22:25 +0300
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 20:05 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-10-07 23:25 +0300
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-07 22:36 +0200
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 22:05 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-09 16:36 +0200
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-07 16:49 -0400
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-07 22:13 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-08 05:46 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-10-08 12:05 -0400
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-08 22:55 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-28 19:58 +0300
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-29 15:44 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-09-30 13:57 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-30 17:50 +0300
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 11:47 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-30 18:03 +0200
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-30 17:49 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-01 06:58 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-02 20:38 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-02 21:23 -0700
Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-03 11:12 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:45 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 08:29 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 18:29 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-10 14:18 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 17:31 +0000
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-11 15:40 +0000
Re: Rust Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-11 14:26 -0400
Re: Rust cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:14 +0000
Re: Rust Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-12 21:15 +0000
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 19:13 +0000
Re: Rust (was: Optimization by programmers) Michael S <already5chosen@yahoo.com> - 2026-10-10 22:28 +0300
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-11 09:27 +0000
Re: Rust (was: Optimization by programmers) Michael S <already5chosen@yahoo.com> - 2026-10-11 22:43 +0300
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 05:01 -0700
Re: Rust (was: Optimization by programmers) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 15:21 +0000
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-07 05:41 -0700
Re: Rust (was: Optimization by programmers) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-07 14:23 +0000
Re: Rust (was: Optimization by programmers) George Neuner <gneuner2@comcast.net> - 2026-10-06 21:18 -0400
Re: Rust (was: Optimization by programmers) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 22:17 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-10-03 14:25 +0200
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-03 21:08 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:29 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 01:49 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-12 13:05 +0000
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 12:29 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-28 15:34 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-29 12:42 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-28 10:54 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-27 17:39 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-27 21:23 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-29 16:53 +0000
Re: Optimization by programmers EricP <ThatWouldBeTelling@thevillage.com> - 2026-09-27 11:46 -0400
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-27 14:42 -0400
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-28 06:12 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-28 07:57 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-28 08:56 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-28 11:06 +0200
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-28 14:32 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-27 16:40 +0200
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-09-28 01:58 -0400
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-29 10:16 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-02 05:31 +0000
Re: Optimization by programmers MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-24 19:52 +0000
Re: Optimization by programmers Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-24 13:52 -0700
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-25 11:06 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-25 05:43 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 05:49 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-09-23 10:45 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-25 05:39 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 14:36 +0000
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-25 14:45 +0000
Re: Optimization by programmers aph@littlepinkcloud.invalid - 2026-10-04 08:15 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 12:15 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 14:16 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 16:36 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-10-04 17:46 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-04 20:04 +0200
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-06 02:17 +0000
Re: Optimization by programmers David Brown <david.brown@hesbynett.no> - 2026-10-06 10:05 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-19 12:06 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-19 15:56 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-20 10:46 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 14:24 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-20 11:52 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 15:09 +0300
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-21 05:27 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 12:13 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-20 15:35 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 16:43 +0000
Re: Optimization by programmers Michael S <already5chosen@yahoo.com> - 2026-09-21 20:23 +0300
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-20 11:49 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-20 07:31 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-22 20:01 +0200
Re: Optimization by programmers scott@slp53.sl.home (Scott Lurndal) - 2026-09-22 20:52 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-23 13:17 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-22 16:50 -0700
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-03 05:28 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-03 04:38 -0700
Re: Optimization by programmers cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-05 13:55 +0000
Re: Optimization by programmers antispam@fricas.org (Waldek Hebisch) - 2026-10-05 22:54 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-10-06 06:35 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-06 02:53 -0700
Re: Optimization by programmers Stefan Monnier <monnier@iro.umontreal.ca> - 2026-10-06 14:55 -0400
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-21 15:16 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-22 06:15 +0000
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-24 17:05 +0000
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-26 09:18 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-22 19:57 +0200
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-14 16:31 +0200
Re: Optimization by programmers Thomas Koenig <tkoenig@netcologne.de> - 2026-09-14 16:58 +0000
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:45 -0700
Re: Optimization by programmers Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-09-15 06:53 -0700
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 17:21 +0200
Re: Optimization by programmers quadibloc@invalid.com (John Savard) - 2026-09-15 16:00 +0000
Re: Optimization by programmers Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-15 19:40 +0200
Re: Optimization by programmers anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-18 15:58 +0000
Re: Styles of addressing David Brown <david.brown@hesbynett.no> - 2026-09-11 10:15 +0200
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-11 08:54 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-11 10:54 +0000
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-06 15:56 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-06 21:46 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-01 12:07 -0700
Re: Styles of addressing MitchAlsup <user5857@newsgrouper.org.invalid> - 2026-09-01 20:04 +0000
Re: PDP-10 Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 01:15 +0000
Re: PDP-10 Styles of addressing Kragen Javier Sitaker <kragen@canonical.org> - 2026-09-02 13:55 -0300
Re: PDP-10 Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 17:32 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-02 02:42 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-02 11:19 -0700
Re: Styles of addressing Thomas Koenig <tkoenig@netcologne.de> - 2026-09-02 20:39 +0000
Re: Styles of addressing scott@slp53.sl.home (Scott Lurndal) - 2026-09-02 21:09 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-02 22:01 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-08 08:34 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 01:37 +0000
Re: Styles of addressing Terje Mathisen <terje.mathisen@tmsw.no> - 2026-09-09 08:25 +0200
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-09 08:13 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-09 08:43 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-10 05:41 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-10 17:16 +0000
Re: Styles of addressing Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-09-12 02:29 +0000
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 07:49 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-11 23:30 -0700
Re: Styles of addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-09-12 08:23 +0000
Re: Styles of addressing John Levine <johnl@taugh.com> - 2026-09-12 18:34 +0000
Re: Styles of addressing Stephen Fuld <sfuld@alumni.cmu.edu.invalid> - 2026-09-07 17:15 -0700
Page 11 of 24 — ← Prev page 1 … 9 10 [11] 12 13 … 24 Next page →
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-23 05:40 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118voo5$1ff81$1@dont-email.me> |
| In reply to | #118124 |
Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>Anton Ertl <anton@mips.complang.tuwien.ac.at> schrieb:
>>
>>> I don't think that they expected that compiler writers on a
>>> twos-complement machine that does not trap on signed overflow would
>>> say: Hey, signed overflow is undefined behaviour, let's assume it
>>> never happens, and silently miscompile some (not all) programs that
>>> actually perform signed overflows.
>>
>>Define "miscompile".
>
> If a compiler produces an unintended behaviour for an existing, tested
> program that works as intended with an earlier version of the compiler.
Two points: gcc 16 is a different compiler from gcc 15 and all
previous versions. For gcc 16.2 vs. gcc 16.1, I would agree
(partially), see below.
There is a reason why such things as
https://gcc.gnu.org/gcc-16/porting_to.html are necessary.
Assume something worked in gcc 14 and was broken in gcc15
(i.e. did not work according to the language specification).
Also assume that two programs were tested, one according to
the correct gcc14 behavior and one according to the incorrect
gcc15 behavior. Your definition would be impossible to fulfill
in that case.
>>According to which specification?
>
> If you want that, go for the specification of a conforming program in
> the C standard.
I disagree. AFAIK, it has been argued that
PRINT *,42
END
is a conforming C program because the gfortran command is a
conforming C implementation (the driver also compiles C).
>Compiling a conforming program compiled with a
> different compiler or on a different architecture to different
> behaviour is ok with me, compiling it on the same architecture with a
> new version of the same compiler into different behaviour is
> miscompilation.
gcc 16 is a different compiler from gcc15, but even there
you would like to make regression fixes between gcc 16.2 and
gcc 16.1 impossible.
>
>>In Fortran, for example, signed
>>integer overflow is just an error, so a compiler that would not
>>optimize on the assumption of absence of integer overflow would
>>be doing a poor jobs.
>
> What does "just an error" mean? Does it trap?
No. It can issue a diagnostic at compile-time, issue a diagnostic
at run-time with or with aborting the program, continue with
unpredictable results (including, according to an old quip. starting
World War III if the right operational hardware has been installed).
ar anything else you might dream up. (But the "starting
World War III part is now left to AIs, in the absence of
any specification).
The standard makes no such guarantees. The programmer must
("shall") not to that, that's all - it is a two-way contract.
The compiler guarantees that violations of constraints are reported
(modulo bugs), the programmer guarantees that he does not violate
"shall" constraints.
>
>>> Still, even if they did not, there are still differences between
>>> hardware and between existing compilers to reconcile (although a lot
>>> of the old hardware variations have died out), and getting consensus
>>> on a completely specified C is unlikely. E.g., Pascal Cuoq, Matthew
>>> Flatt, and John Regehr tried to create a more completely specified
>>> "friendly C", and did not find consensus:
>>><https://blog.regehr.org/archives/1287>.
>>
>>People who want that kind of language know where to find it,
>
> I think these efforts are the result of C compiler maintainers and
> their fanboys
You're trying to make friends, I know :-) But you might think
again - if you actually want to achieve something, that attitude
is not going to help a lot.
But if you are serious about this, and your opinion reflects
that of a sufficient number of other people, you have a choice.
You can fork either gcc or LLVM and yank out all the optimizations
that you consider undesirable. The cost of that is almost zero.
If you get enough capable people on board to work on your vision,
and enough people use it, you will succeed. If your position
is a very lonely one, as I suspect, you will fail. But
it is a hypothesis that can be tested.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-23 06:45 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86tsngrsi8.fsf@linuxsc.com> |
| In reply to | #118140 |
Thomas Koenig <tkoenig@netcologne.de> writes: [...] > AFAIK, it has been argued that > > PRINT *,42 > END > > is a conforming C program because the gfortran command is a > conforming C implementation (the driver also compiles C). How a compiler is invoked can affect whether it is (part of) a conforming C implmentation. For example gcc -x c -std=c99 -pedantic ... asks gcc to be a conforming C compiler; but if instead the invocation is gcc -x c++ ... then how gcc behaves is not consistent with being a conforming C compiler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-22 14:32 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118tshf$r2kv$1@dont-email.me> |
| In reply to | #118117 |
On 21/09/2026 19:17, Anton Ertl wrote: > Stefan Monnier <monnier@iro.umontreal.ca> writes: >> Anton Ertl [2026-09-19 06:25:13] wrote: > [...] >> The traditional "-O<N>" flags are a way to state how much you're willing >> to get worse performance in exchange for the opportunity to maybe get >> better performance. > > The gcc manual states: > > With '-O', the compiler tries to reduce code size and execution > time, without performing any optimizations that take a great deal > of compilation time. > [...] > [about -O2] As > compared to '-O', this option increases both compilation time and > the performance of the generated code. > [...] > [about -O3] Optimize yet more. > > In earlier gcc versions, it made statements along the lines that -O3 > may be a mixed bag, but that's gone. It must have been removed a /long/ time ago, because it is not in manual pages that I checked (the oldest convenient version is 2.95.3). But it is certainly the case that -O3 is a mixed bag - in particular, more aggressive unrolling and inlining can lead to larger code that can reduce the effect of caches, branch prediction, and that kind of thing. In microcontroller work, -Os is often used to put a stronger emphasis on size optimisations. I have noticed there are sometimes "blips" - cases where "-O2" leads to smaller code than "-Os", or where "-Os" leads to faster code than "-O2". And there can sometimes be cases where the speed/size tradeoffs are unreasonable - significantly slower code for very minor size improvements, or vice versa. It is clearly not the case that all optimisations improve all code, or that increasing "n" in "-On" always gives faster results. Each optimisation flag in a compiler enables one or more transformation passes that might improve some code but might also have detrimental effects in some cases. Lower "-On" numbers will include the passes with high statistical rates of improvement and low risk of worsening code, while the passes enabled with higher flags will have worse ratios and longer compiler times. Flags with significant risks of making code a lot worse are usually not enabled by any "-On" flag, and require manual choice. (But no one will claim that gcc, clang, or any other compiler is perfect here.) I think one thing that is sometimes forgotten in all this, and could usefully be mentioned on the gcc manual page for optimisation, is that cpu architecture flags can make a significant difference. The step from "-O2" to "-O2 -march=native" is likely to be a lot bigger than the step from "-O2" to "-O3" in performance, with much lower risks of slowdowns. > >>> But if optimizer writers strove to "improve the convenience to write >>> efficient code" instead of just improving benchmark results, maybe >>> such paradoxical effects can be avoided. >> >> In general it's hard to completely avoid paradoxical effects. > > I referred to a specific paradoxical effect, not completely avoiding > all of them: The effect of programmers who, instead of working on > making the code faster through source-level changes, have to invest > time into avoiding getting it miscompiled. > By "miscompiled", do you mean incorrect object code, or object code that did not have the performance the programmer expected or hoped for? >> But as >> for the problems you mention w.r.t UB, I think it's just the result of >> poor semantics, for which I guess we (language semanticists) are partly >> to blame: we have developed fairly good tools to design sane language >> specs in general, > > I violently disagree. The C89 standard (just to name one) is a > partial specification not because the original C standards people were > poor at specifying semantics, but because given the differences > between the compilers out there and the hardware out there, the > easiest way to reach a consensus is to leave some parts unspecified. I have never spoken to the C standards committee or writers, either of current standard versions or the original C89 standard, or writers of pre-standard C specifications. So I cannot in any way claim to know their thoughts or motivations. I also have not seen any documentation that suggests what they might have thought about "optimisation on the assumption that undefined behaviour does not occur" - in either direction. (It has been mentioned that, for example, a two's complement implementation could use wrapping signed arithmetic - but I have never seen a suggestion that this behaviour should be encouraged or expected just because a machine uses two's complement.) I do, however, believe that the folks being the C language design and specifications through all its changes are accomplished and experienced computer scientists. They will have been aware of the "garbage in, garbage out" principle, and that there is no reason to expect any particular result or effect when you apply a function or operator to something outside its defined semantics. You do not ask "what happens if my signed integer arithmetic overflows?" or "what happens when I access an array out of bounds?" - rather, it is your responsibility as a C programmer to make sure that never happens. The prime reason C does not define behaviour here is not that different hardware or compilers handle things differently, but that there is no sensible definition that could be made. Remember, C has a perfectly good way to say "this is determined by the hardware or the implementation" - it is "implementation-defined behaviour". It has a perfectly good way to say that "this operation could result in any value" - it is "unspecified behaviour" or "unspecified value". When the C standards writers say something is "undefined behaviour", rather than "implementation defined" or "unspecified", it is my belief that they did so intentionally and knowingly. I have at times been accused of arrogance, usually quite fairly, but I am not arrogant enough to suppose that I know when the C standards committee made mistakes here or intended to write something differently. So I cannot accept an argument that C's undefined behaviours are either due to hardware differences, or laziness. It simply does not fit with the level of expertise and effort that have gone into the language and its standards. And note that in C23 the macro "unreachable()" was added with the sole semantics being "If a macro invocation unreachable() is reached during execution, the behavior is undefined" and "The program execution shall not reach such an invocation". The justification is for better diagnostics and optimisations. (Some people are of the opinion that later C standards deviate from the philosophy of early C - that may or may not be a fair opinion, and opinions will also differ on whether that is a good thing or a bad thing.) I don't know whether or not the "founding fathers" of C intended or expected compilers to optimise on the assumption that UB did not occur. But I am confident that they considered a program to be broken if execution reached a point where the behaviour was not defined in an implementation (something may be UB in the C standards yet defined by an implementation). I am confident that if they intended that adding two ints must always return a valid int even if there is an overflow, they would have said its result was implementation-defined or an unspecified value. The behaviour is intentionally left wide open, without restriction. It is, of course, possible that they did not foresee quite how this would pan out in modern compilers. In particular, they may not have predicted "time-travel" optimisations. However, authors of more modern C standards - say, C11 onwards - know about them and have could have explicitly outlawed them if they were considered to be invalid. > > I don't think that they expected that compiler writers on a > twos-complement machine that does not trap on signed overflow would > say: Hey, signed overflow is undefined behaviour, let's assume it > never happens, and silently miscompile some (not all) programs that > actually perform signed overflows. It gives a speedup in some SPEC > program (How much? Don't know, but I am sure it exists); ok, it > breaks this other SPEC program, let's special-case the optimization to > avoid this breakage. > Regardless of what was and was not intended by the original designers of the C language, compiler developers must take practical considerations if their tool is to be useful to people. A compiler that implements multiplication by repeated addition could be fully conforming, but users would quickly look for something that gave more efficient results. For heavily used compilers, there is a strong (but not overpowering) push towards backwards compatibility. This is why they have heavy regression tests, and pre-release versions are tested with large samples of important existing code. If this gives unexpected results, these must be dealt with - was it a bug in the new compiler (in which case the fix is obvious), or was it a bug in the old source code? Those cases are more complicated - sometimes the old code must be fixed, but sometimes the incorrect source code is too common, idomatic or important and the compiler must, in effect, support additional semantics to retain the old accidental semantics. > My impression is that the C compiler maintainers and some others have > fallen in love with the idea of optimizing based on assuming that > undefined behaviour does not happen; e.g., I have read the claim that > this is the only thing that gives C an edge over other programming > languages (or somesuch). So I think that while the C89 committee may > not have thought of such things, recent C standardization committees > probably have. I am sure you are right that more recent standards committees consider optimisations here more than older ones. "restrict" was added to C99 for optimisation purposes (to catch up with Fortran) - it is, in effect, specified by saying that the programmer promises to follow certain additional rules in the way they access data or the result is undefined behaviour. It is very much intended that compilers optimise "restrict" by assuming that at least a particular type of UB does not occur. In C23, there are several features that are entirely for optimisation - the aforementioned "unreachable()" macro, as well as the "reproducible" and "unsequenced" attributes. > > Still, even if they did not, there are still differences between > hardware and between existing compilers to reconcile (although a lot > of the old hardware variations have died out), and getting consensus > on a completely specified C is unlikely. E.g., Pascal Cuoq, Matthew > Flatt, and John Regehr tried to create a more completely specified > "friendly C", and did not find consensus: > <https://blog.regehr.org/archives/1287>. There are two key problems with UB that stand in the way of this kind of initiative. One is that many compilers provide consistent (and sometimes even documented) behaviour for some things that are UB in the C standards. Code relying on these behaviours is valid and safe, but non-portable. But different compilers (or the same compiler but different targets) could easily have different semantics, making it very difficult to agree on any one choice. Secondly, many programmers write code on the assumption that certain UB has certain consistent and reliable behaviour - even though it is not documented anywhere. It is code like that which could benefit from a "friendly C" (a poor choice of name, IMHO, but that's entirely subjective) variant. But it is also such code that makes a "friendly C" variant hard to define - such code is hard to identify, and the expected behaviour can be even harder to find, specify, and consistently describe. > > But fortunately a completely specified C is not necessary, a > willingness to preserve the behaviour of existing working programs > compiled with an earlier version of the same compiler is. Read more > about it in <https://www.complang.tuwien.ac.at/papers/ertl17kps.pdf>. > I think it is entirely reasonable to keep old compiler versions around and use them for old code. Even if the code is clinically free of any UB, there can be implementation-defined behaviour, differences in code size and timing, support for features or targets that are removed in later toolchain versions, etc. I think it is entirely unreasonable to try to specify that new compilers should have defined specifications to implement the "semantics" that older compilers used for particular types of undefined behaviour. These semantics will, for the most part, be poorly defined and can often be inconsistent - many programs with UB work by luck, not design. > Linux commits to preserving user-space behaviour (whether standard or > not), everything I have heard from people claiming to speak for gcc > and clang maintainers has been in the opposite direction. So I blame > the gcc and clang maintainers for the undefined-behaviour shenanigans > they perform. > Linux commits to preserving the /defined/ behaviour of user-space APIs. If an API is defined to take a valid file descriptor as a parameter, then programs that use that API with a valid file descriptor will always work the same way. What happens if you give it an invalid parameter is another matter. Maybe your program will receive an error return, or maybe it will be given a kill signal. Maybe some extra bits in the parameter will be ignored in earlier versions of Linux and later versions will use those bits for extra flags. Or maybe the API will define exactly what you get for any possible parameter value. But if a particular invalid value of the parameter lets you gain access to root-owned files, due to a bug in the kernel, you can be very sure that this user-space behaviour will /not/ be preserved. It's a very good thing to avoid changing defined and documented behaviour unless there is extremely good reason to do so. It's a very bad thing to commit to avoid changing undefined and undocumented behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-22 15:21 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <118uv1g$18lk0$1@dont-email.me> |
| In reply to | #118126 |
On 9/22/2026 5:32 AM, David Brown wrote: > On 21/09/2026 19:17, Anton Ertl wrote: >> Stefan Monnier <monnier@iro.umontreal.ca> writes: >>> Anton Ertl [2026-09-19 06:25:13] wrote: >> [...] >>> The traditional "-O<N>" flags are a way to state how much you're willing >>> to get worse performance in exchange for the opportunity to maybe get >>> better performance. >> >> The gcc manual states: >> >> With '-O', the compiler tries to reduce code size and execution >> time, without performing any optimizations that take a great deal >> of compilation time. >> [...] >> [about -O2] As >> compared to '-O', this option increases both compilation time and >> the performance of the generated code. >> [...] >> [about -O3] Optimize yet more. >> >> In earlier gcc versions, it made statements along the lines that -O3 >> may be a mixed bag, but that's gone. > > It must have been removed a /long/ time ago, because it is not in manual > pages that I checked (the oldest convenient version is 2.95.3). But it > is certainly the case that -O3 is a mixed bag - in particular, more > aggressive unrolling and inlining can lead to larger code that can > reduce the effect of caches, branch prediction, and that kind of thing. > > In microcontroller work, -Os is often used to put a stronger emphasis on > size optimisations. I have noticed there are sometimes "blips" - cases > where "-O2" leads to smaller code than "-Os", or where "-Os" leads to > faster code than "-O2". And there can sometimes be cases where the > speed/size tradeoffs are unreasonable - significantly slower code for > very minor size improvements, or vice versa. > > It is clearly not the case that all optimisations improve all code, or > that increasing "n" in "-On" always gives faster results. Each > optimisation flag in a compiler enables one or more transformation > passes that might improve some code but might also have detrimental > effects in some cases. Lower "-On" numbers will include the passes with > high statistical rates of improvement and low risk of worsening code, > while the passes enabled with higher flags will have worse ratios and > longer compiler times. Flags with significant risks of making code a > lot worse are usually not enabled by any "-On" flag, and require manual > choice. (But no one will claim that gcc, clang, or any other compiler > is perfect here.) > > I think one thing that is sometimes forgotten in all this, and could > usefully be mentioned on the gcc manual page for optimisation, is that > cpu architecture flags can make a significant difference. The step from > "-O2" to "-O2 -march=native" is likely to be a lot bigger than the step > from "-O2" to "-O3" in performance, with much lower risks of slowdowns. > >> >>>> But if optimizer writers strove to "improve the convenience to write >>>> efficient code" instead of just improving benchmark results, maybe >>>> such paradoxical effects can be avoided. >>> >>> In general it's hard to completely avoid paradoxical effects. >> >> I referred to a specific paradoxical effect, not completely avoiding >> all of them: The effect of programmers who, instead of working on >> making the code faster through source-level changes, have to invest >> time into avoiding getting it miscompiled. >> > > By "miscompiled", do you mean incorrect object code, or object code that > did not have the performance the programmer expected or hoped for? > >>> But as >>> for the problems you mention w.r.t UB, I think it's just the result of >>> poor semantics, for which I guess we (language semanticists) are partly >>> to blame: we have developed fairly good tools to design sane language >>> specs in general, >> >> I violently disagree. The C89 standard (just to name one) is a >> partial specification not because the original C standards people were >> poor at specifying semantics, but because given the differences >> between the compilers out there and the hardware out there, the >> easiest way to reach a consensus is to leave some parts unspecified. > > I have never spoken to the C standards committee or writers, either of > current standard versions or the original C89 standard, or writers of > pre-standard C specifications. So I cannot in any way claim to know > their thoughts or motivations. I also have not seen any documentation > that suggests what they might have thought about "optimisation on the > assumption that undefined behaviour does not occur" - in either > direction. (It has been mentioned that, for example, a two's complement > implementation could use wrapping signed arithmetic - but I have never > seen a suggestion that this behaviour should be encouraged or expected > just because a machine uses two's complement.) > > I do, however, believe that the folks being the C language design and > specifications through all its changes are accomplished and experienced > computer scientists. They will have been aware of the "garbage in, > garbage out" principle, and that there is no reason to expect any > particular result or effect when you apply a function or operator to > something outside its defined semantics. You do not ask "what happens > if my signed integer arithmetic overflows?" or "what happens when I > access an array out of bounds?" - rather, it is your responsibility as a > C programmer to make sure that never happens. The prime reason C does > not define behaviour here is not that different hardware or compilers > handle things differently, but that there is no sensible definition that > could be made. > > Remember, C has a perfectly good way to say "this is determined by the > hardware or the implementation" - it is "implementation-defined > behaviour". It has a perfectly good way to say that "this operation > could result in any value" - it is "unspecified behaviour" or > "unspecified value". > > When the C standards writers say something is "undefined behaviour", > rather than "implementation defined" or "unspecified", it is my belief > that they did so intentionally and knowingly. I have at times been > accused of arrogance, usually quite fairly, but I am not arrogant enough > to suppose that I know when the C standards committee made mistakes here > or intended to write something differently. > > So I cannot accept an argument that C's undefined behaviours are either > due to hardware differences, or laziness. It simply does not fit with > the level of expertise and effort that have gone into the language and > its standards. > > And note that in C23 the macro "unreachable()" was added with the sole > semantics being "If a macro invocation unreachable() is reached during > execution, the behavior is undefined" and "The program execution shall > not reach such an invocation". I don't have a problem with the inclusion of "unreachable()", but can you give a possible rationale for making its behavior "undefined" as opposed to say "implementation defined"? Yes, it would make the compiler implementers do some work to document whatever they decided to do, but are there any other reasons? -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2026-09-23 05:23 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <2026Sep23.072326@mips.complang.tuwien.ac.at> |
| In reply to | #118135 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >On 9/22/2026 5:32 AM, David Brown wrote: >> And note that in C23 the macro "unreachable()" was added with the sole >> semantics being "If a macro invocation unreachable() is reached during >> execution, the behavior is undefined" and "The program execution shall >> not reach such an invocation". > >I don't have a problem with the inclusion of "unreachable()", but can >you give a possible rationale for making its behavior "undefined" as >opposed to say "implementation defined"? The idea here is obviously to use this macro only when its invocation really is unreachable, and in that case it has no effect on the behaviour. How should an implementation document what happens when the invocation of this macro actually is reachable? The effect depends on the surrounding code and the transformations in the compiler. And what would a programmer do with this documentation? - anton -- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2026-09-23 14:01 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <ZYQsS.206123$ia3.112921@fx16.iad> |
| In reply to | #118139 |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>On 9/22/2026 5:32 AM, David Brown wrote:
>>> And note that in C23 the macro "unreachable()" was added with the sole
>>> semantics being "If a macro invocation unreachable() is reached during
>>> execution, the behavior is undefined" and "The program execution shall
>>> not reach such an invocation".
>>
>>I don't have a problem with the inclusion of "unreachable()", but can
>>you give a possible rationale for making its behavior "undefined" as
>>opposed to say "implementation defined"?
>
>The idea here is obviously to use this macro only when its invocation
>really is unreachable, and in that case it has no effect on the
>behaviour.
>
>How should an implementation document what happens when the invocation
>of this macro actually is reachable? The effect depends on the
>surrounding code and the transformations in the compiler.
IME, the annotation is there to squash compiler warnings.
/**
* Restore the state of the current core to the most recent
* rollback state saved. This will result in the rollback handler
* provided to the ::push function to be invoked.
*/
inline void
c_rollback::restore(uint64 rval)
{
_longjmp(&rb_state, rval);
/* NOTREACHED */
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-23 16:52 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1190p3i$1rdis$1@dont-email.me> |
| In reply to | #118147 |
On 23/09/2026 16:01, Scott Lurndal wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes:
>>> On 9/22/2026 5:32 AM, David Brown wrote:
>>>> And note that in C23 the macro "unreachable()" was added with the sole
>>>> semantics being "If a macro invocation unreachable() is reached during
>>>> execution, the behavior is undefined" and "The program execution shall
>>>> not reach such an invocation".
>>>
>>> I don't have a problem with the inclusion of "unreachable()", but can
>>> you give a possible rationale for making its behavior "undefined" as
>>> opposed to say "implementation defined"?
>>
>> The idea here is obviously to use this macro only when its invocation
>> really is unreachable, and in that case it has no effect on the
>> behaviour.
>>
>> How should an implementation document what happens when the invocation
>> of this macro actually is reachable? The effect depends on the
>> surrounding code and the transformations in the compiler.
>
> IME, the annotation is there to squash compiler warnings.
>
> /**
> * Restore the state of the current core to the most recent
> * rollback state saved. This will result in the rollback handler
> * provided to the ::push function to be invoked.
> */
> inline void
> c_rollback::restore(uint64 rval)
> {
> _longjmp(&rb_state, rval);
>
> /* NOTREACHED */
> }
>
That is certainly a valid use of "unreachable()", but it would be wrong
to suggestion it is the main intended or expected use.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-23 08:01 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1190pk8$1sj8l$1@dont-email.me> |
| In reply to | #118139 |
On 9/22/2026 10:23 PM, Anton Ertl wrote: > Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: >> On 9/22/2026 5:32 AM, David Brown wrote: >>> And note that in C23 the macro "unreachable()" was added with the sole >>> semantics being "If a macro invocation unreachable() is reached during >>> execution, the behavior is undefined" and "The program execution shall >>> not reach such an invocation". >> >> I don't have a problem with the inclusion of "unreachable()", but can >> you give a possible rationale for making its behavior "undefined" as >> opposed to say "implementation defined"? > > The idea here is obviously to use this macro only when its invocation > really is unreachable, and in that case it has no effect on the > behaviour. Yes. Although the programmer may have made an error by coding it when it is, in fact, reachable. > How should an implementation document what happens when the invocation > of this macro actually is reachable? The effect depends on the > surrounding code and the transformations in the compiler. Fair enough. I am not saying otherwise. Just document it. > > And what would a programmer do with this documentation? He might know that a particular error he received was possibly or alternatively was not from the macro. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-23 10:38 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119035d$1il2u$1@dont-email.me> |
| In reply to | #118135 |
On 23/09/2026 00:21, Stephen Fuld wrote: > On 9/22/2026 5:32 AM, David Brown wrote: >> And note that in C23 the macro "unreachable()" was added with the sole >> semantics being "If a macro invocation unreachable() is reached during >> execution, the behavior is undefined" and "The program execution shall >> not reach such an invocation". > > I don't have a problem with the inclusion of "unreachable()", but can > you give a possible rationale for making its behavior "undefined" as > opposed to say "implementation defined"? Yes, it would make the > compiler implementers do some work to document whatever they decided to > do, but are there any other reasons? > Good question. There is a sort of partial ordering (or lattice order) of behaviour specifications. "undefined behaviour" is at the bottom - it implements nothing, and anything else can implement it. "implementation-defined" is stronger. If the standards say "UB", then an implementation can define behaviour more concretely. If the standards say "IB", then the implementation cannot turn it into "UB". So "UB" in the standards clearly gives the most flexibility to the implementation. The big disadvantage of making something like this "IB" is not that the compiler implementers need to document their handling, but that they need to have a specification for it and stick to that - users must be able to rely on IB being consistent. Different types of handling for hitting "unreachable()" can include compiler optimisation on the assumption that it is never reached, generating a target "trap" instruction, generating a "breakpoint" when debugging, printing out an error message and terminating, calling a user-defined function that sends an angry email to the developer, and tracking all possible code flows at build time and giving a compiler warning if it can, in fact, be reached. Some users will prefer one method, others will prefer a different one, and many will change depending on what they are doing. Crucially, compilers may change what they support over time. A compiler cannot document "IB" as "depending on flags, this might be treated as UB, or give a trap, or perhaps do something else in the future". But it /can/ do exactly that if the standards say it is "UB". It is also important to note that gcc, clang, icc, and many other compilers have had something like this for decades - like __builtin_unreachable() - which are implemented exactly as "undefined behaviour" in these tools. This is, as far as I can tell, the proposal paper that led to "unreachable()" being added to the C standards: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2826.pdf> """ We propose the feature unreachable to specify branches in the control flow of a program that will never be reached. The aim is to provide means for the user to express guarantees about the effective control flow that will be executed by a program. Compilers may then apply aggressive optimizations that otherwise would not be possibly or that would rely on the detection of undefined behavior for certain input combinations. """ The C++ version is : <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0627r6.pdf> The discussion about the definition is : """ What is the best way to define the attribute's effect? The author feels that the best way is to make the behavior of std::unreachable() be undefined. There are several reasons: * std::unreachable() causing undefined behavior means that the Standard would not prescribe any particular action, leaving open many possible implementation actions. * Some compilers already associate being unreachable to undefined behavior. Clang’s documentation states that __builtin_unreachable() “has completely undefined behavior”. * Optimizing under the assumption that a statement is unreachable, and thus having unpredictable behavior if the statement is in fact reachable, falls naturally under "undefined behavior". * An alternative would be to issue a trap if std::unreachable() is executed. This could be used in "debug builds", for example. Such a trap falls under "undefined behavior". * Being undefined behavior implies what happens if a constexpr function calls std::unreachable(): it's not a constant-expression, by (N4713) [expr.const]/2.6 In the author’s opinion, it is not undefined behavior itself that is the problem, but rather unexpected undefined behavior. C++ will always have undefined behavior; this is unavoidable. Situations in which undefined behavior occurs unexpectedly are problematic for programmers, because they often lead to subtle bugs, or unexpected compiler optimizations. However, std::unreachable() is expected undefined behavior: a programmer using it knows that undefined behavior will occur there and is making a calculated risk in using it. """
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-23 07:54 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1190p7d$1sdou$1@dont-email.me> |
| In reply to | #118143 |
On 9/23/2026 1:38 AM, David Brown wrote: > On 23/09/2026 00:21, Stephen Fuld wrote: >> On 9/22/2026 5:32 AM, David Brown wrote: > >>> And note that in C23 the macro "unreachable()" was added with the >>> sole semantics being "If a macro invocation unreachable() is reached >>> during execution, the behavior is undefined" and "The program >>> execution shall not reach such an invocation". >> >> I don't have a problem with the inclusion of "unreachable()", but can >> you give a possible rationale for making its behavior "undefined" as >> opposed to say "implementation defined"? Yes, it would make the >> compiler implementers do some work to document whatever they decided >> to do, but are there any other reasons? >> > > Good question. > > > There is a sort of partial ordering (or lattice order) of behaviour > specifications. "undefined behaviour" is at the bottom - it implements > nothing, and anything else can implement it. "implementation-defined" > is stronger. If the standards say "UB", then an implementation can > define behaviour more concretely. If the standards say "IB", then the > implementation cannot turn it into "UB". So "UB" in the standards > clearly gives the most flexibility to the implementation. In one sense, yes. But in another sense, saying IB doesn't in any way constrain what the code for that implementation does - only that the implementer documents what the code that is written does. > The big disadvantage of making something like this "IB" is not that the > compiler implementers need to document their handling, but that they > need to have a specification for it and stick to that - users must be > able to rely on IB being consistent. Yes, but it allows that behavior to be anything the implementer chooses, including doing different things for different situations. The implementer has written some code to handle it. AFAICT the only difference is that IB requires the implementer document that code. > Different types of handling for > hitting "unreachable()" can include compiler optimisation on the > assumption that it is never reached, generating a target "trap" > instruction, generating a "breakpoint" when debugging, printing out an > error message and terminating, calling a user-defined function that > sends an angry email to the developer, and tracking all possible code > flows at build time and giving a compiler warning if it can, in fact, be > reached. Absolutely agreed, and perhaps other choices as well. :-) And perhaps even different choices depending upon the specifics of the code around it. ID doesn't preclude any choices here. > Some users will prefer one method, others will prefer a > different one, and many will change depending on what they are doing. Sure. And making the implementer document their implementation would give the user a basis to choose whether to use that capability in a particular situation, or indeed perhaps (though unlikely) choose which compiler implementation to use. > Crucially, compilers may change what they support over time. A compiler > cannot document "IB" as "depending on flags, this might be treated as > UB, or give a trap, or perhaps do something else in the future". But > it /can/ do exactly that if the standards say it is "UB". I don't see why IB can't be dependent on flags. In fact that might be useful. The compiler already does something. Just document what it does. And as for future choices, nothing in IB prevents future changes, as long as they are documented. > It is also important to note that gcc, clang, icc, and many other > compilers have had something like this for decades - like > __builtin_unreachable() - which are implemented exactly as "undefined > behaviour" in these tools. OK. But these implementations did *something* with these features. I am not asking them to change that in any way. Just document what that something is. > This is, as far as I can tell, the proposal paper that led to > "unreachable()" being added to the C standards: > > <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2826.pdf> > > """ > We propose the feature unreachable to specify branches in the control > flow of a program that will never be reached. The aim is to provide means > for the user to express guarantees about the effective control flow that > will be executed by a program. Compilers may then apply aggressive > optimizations that otherwise would not be possibly or that would rely on > the detection of undefined behavior for certain input combinations. Sounds reasonable to me. > """ > > The C++ version is : > > <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0627r6.pdf> > > The discussion about the definition is : > > """ > What is the best way to define the attribute's effect? The author feels > that the best way is to make the behavior of std::unreachable() be > undefined. There are several reasons: > > * std::unreachable() causing undefined behavior means that the Standard > would not prescribe any particular action, leaving open many possible > implementation actions. So does IB. > > * Some compilers already associate being unreachable to undefined > behavior. Clang’s documentation states that __builtin_unreachable() “has > completely undefined behavior”. > > * Optimizing under the assumption that a statement is unreachable, and > thus having unpredictable behavior if the statement is in fact > reachable, falls naturally under "undefined behavior". > > * An alternative would be to issue a trap if std::unreachable() is > executed. This could be used in "debug builds", for example. Such a trap > falls under "undefined behavior". > > * Being undefined behavior implies what happens if a constexpr function > calls std::unreachable(): it's not a constant-expression, by (N4713) > [expr.const]/2.6 These seem to me to be sort of like "because we've always done it that way". While I agree that is true, it doesn't make it right. > In the author’s opinion, it is not undefined behavior itself that is the > problem, but rather unexpected undefined behavior. This seems curious to me. If a behavior is expected, it isn't undefined. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-23 18:24 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1190ufg$1u1p8$1@dont-email.me> |
| In reply to | #118150 |
On 23/09/2026 16:54, Stephen Fuld wrote: > On 9/23/2026 1:38 AM, David Brown wrote: >> On 23/09/2026 00:21, Stephen Fuld wrote: >>> On 9/22/2026 5:32 AM, David Brown wrote: >> >>>> And note that in C23 the macro "unreachable()" was added with the >>>> sole semantics being "If a macro invocation unreachable() is reached >>>> during execution, the behavior is undefined" and "The program >>>> execution shall not reach such an invocation". >>> >>> I don't have a problem with the inclusion of "unreachable()", but can >>> you give a possible rationale for making its behavior "undefined" as >>> opposed to say "implementation defined"? Yes, it would make the >>> compiler implementers do some work to document whatever they decided >>> to do, but are there any other reasons? >>> >> >> Good question. >> >> >> There is a sort of partial ordering (or lattice order) of behaviour >> specifications. "undefined behaviour" is at the bottom - it >> implements nothing, and anything else can implement it. >> "implementation-defined" is stronger. If the standards say "UB", then >> an implementation can define behaviour more concretely. If the >> standards say "IB", then the implementation cannot turn it into "UB". >> So "UB" in the standards clearly gives the most flexibility to the >> implementation. > > In one sense, yes. But in another sense, saying IB doesn't in any way > constrain what the code for that implementation does - only that the > implementer documents what the code that is written does. > No, you are wrong here. And this misunderstanding is key to why it would be very limited to say "unreachable()" should be implementation-defined. From the C standards under "Terms, definitions, and symbols" : """ * Implementation-defined behaviour Unspecified behaviour where each implementation documents how the choice is made. * Undefined behaviour Behaviour, upon use of a nonportable or erroneous program construct of erroneous data, for which this document imposes no requirements. * Unspecified behaviour Behaviour, that results from the use of an unspecified value, or other behaviour upon which this document provides two or more possibilities and imposes no further requirements on which is chosen in any instance. """ IB means the standard gives certain options, and the implementation documents which choices are made. That is completely different from giving the implementation free reign. For example, right-shift of negative integers gives an implementation-defined value - the implementation can say it always gives the value 42, if it documents it, but it is not allowed to say it causes a call to abort() or prints out a run-time error message. > >> The big disadvantage of making something like this "IB" is not that >> the compiler implementers need to document their handling, but that >> they need to have a specification for it and stick to that - users >> must be able to rely on IB being consistent. > > Yes, but it allows that behavior to be anything the implementer chooses, > including doing different things for different situations. The > implementer has written some code to handle it. AFAICT the only > difference is that IB requires the implementer document that code. No. See above. > >> Different types of handling for hitting "unreachable()" can include >> compiler optimisation on the assumption that it is never reached, >> generating a target "trap" instruction, generating a "breakpoint" when >> debugging, printing out an error message and terminating, calling a >> user-defined function that sends an angry email to the developer, and >> tracking all possible code flows at build time and giving a compiler >> warning if it can, in fact, be reached. > > Absolutely agreed, and perhaps other choices as well. :-) And perhaps > even different choices depending upon the specifics of the code around > it. ID doesn't preclude any choices here. > See above. >> Some users will prefer one method, others will prefer a different >> one, and many will change depending on what they are doing. > > Sure. And making the implementer document their implementation would > give the user a basis to choose whether to use that capability in a > particular situation, or indeed perhaps (though unlikely) choose which > compiler implementation to use. > >> Crucially, compilers may change what they support over time. A >> compiler cannot document "IB" as "depending on flags, this might be >> treated as UB, or give a trap, or perhaps do something else in the >> future". But it /can/ do exactly that if the standards say it is "UB". > > I don't see why IB can't be dependent on flags. In fact that might be > useful. The compiler already does something. Just document what it > does. And as for future choices, nothing in IB prevents future changes, > as long as they are documented. See above. I think we mostly agree on what we would like compiler implementations to do, at least in some cases (I am not sure if you like the "anything can happen" case of the compiler assuming unreachable() is never hit). But what you want here is only achievable if the standard says it is UB, not if the standard says it is IB. > >> It is also important to note that gcc, clang, icc, and many other >> compilers have had something like this for decades - like >> __builtin_unreachable() - which are implemented exactly as "undefined >> behaviour" in these tools. > > OK. But these implementations did *something* with these features. I > am not asking them to change that in any way. Just document what that > something is. > The "something" that they say is "If control flow reaches the point of the __builtin_unreachable, the program is undefined." That's the documentation in the gcc manual, along with some examples and use-cases. > >> This is, as far as I can tell, the proposal paper that led to >> "unreachable()" being added to the C standards: >> >> <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2826.pdf> >> >> """ >> We propose the feature unreachable to specify branches in the control >> flow of a program that will never be reached. The aim is to provide >> means for the user to express guarantees about the effective control >> flow that >> will be executed by a program. Compilers may then apply aggressive >> optimizations that otherwise would not be possibly or that would rely >> on the detection of undefined behavior for certain input combinations. > > Sounds reasonable to me. > > >> """ >> >> The C++ version is : >> >> <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p0627r6.pdf> >> >> The discussion about the definition is : >> >> """ >> What is the best way to define the attribute's effect? The author >> feels that the best way is to make the behavior of std::unreachable() >> be undefined. There are several reasons: >> >> * std::unreachable() causing undefined behavior means that the >> Standard would not prescribe any particular action, leaving open many >> possible implementation actions. > > So does IB. > >> >> * Some compilers already associate being unreachable to undefined >> behavior. Clang’s documentation states that __builtin_unreachable() >> “has completely undefined behavior”. >> >> * Optimizing under the assumption that a statement is unreachable, and >> thus having unpredictable behavior if the statement is in fact >> reachable, falls naturally under "undefined behavior". >> >> * An alternative would be to issue a trap if std::unreachable() is >> executed. This could be used in "debug builds", for example. Such a >> trap falls under "undefined behavior". >> >> * Being undefined behavior implies what happens if a constexpr >> function calls std::unreachable(): it's not a constant-expression, by >> (N4713) [expr.const]/2.6 > > These seem to me to be sort of like "because we've always done it that > way". While I agree that is true, it doesn't make it right. > >> In the author’s opinion, it is not undefined behavior itself that is >> the problem, but rather unexpected undefined behavior. > > This seems curious to me. If a behavior is expected, it isn't undefined. > It's a little odd, yes. It's like saying "unreachable()" is defined to be undefined behaviour. I understand what is meant by "expected undefined behaviour", but it is perhaps clumsy wording.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Fuld <sfuld@alumni.cmu.edu.invalid> |
|---|---|
| Date | 2026-09-23 11:20 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119159b$21919$1@dont-email.me> |
| In reply to | #118154 |
On 9/23/2026 9:24 AM, David Brown wrote: > On 23/09/2026 16:54, Stephen Fuld wrote: >> On 9/23/2026 1:38 AM, David Brown wrote: >>> On 23/09/2026 00:21, Stephen Fuld wrote: >>>> On 9/22/2026 5:32 AM, David Brown wrote: >>> >>>>> And note that in C23 the macro "unreachable()" was added with the >>>>> sole semantics being "If a macro invocation unreachable() is >>>>> reached during execution, the behavior is undefined" and "The >>>>> program execution shall not reach such an invocation". >>>> >>>> I don't have a problem with the inclusion of "unreachable()", but >>>> can you give a possible rationale for making its behavior >>>> "undefined" as opposed to say "implementation defined"? Yes, it >>>> would make the compiler implementers do some work to document >>>> whatever they decided to do, but are there any other reasons? >>>> >>> >>> Good question. >>> >>> >>> There is a sort of partial ordering (or lattice order) of behaviour >>> specifications. "undefined behaviour" is at the bottom - it >>> implements nothing, and anything else can implement it. >>> "implementation-defined" is stronger. If the standards say "UB", >>> then an implementation can define behaviour more concretely. If the >>> standards say "IB", then the implementation cannot turn it into "UB". >>> So "UB" in the standards clearly gives the most flexibility to the >>> implementation. >> >> In one sense, yes. But in another sense, saying IB doesn't in any way >> constrain what the code for that implementation does - only that the >> implementer documents what the code that is written does. >> > > No, you are wrong here. And this misunderstanding is key to why it > would be very limited to say "unreachable()" should be implementation- > defined. > > From the C standards under "Terms, definitions, and symbols" : > > """ > * Implementation-defined behaviour > > Unspecified behaviour where each implementation documents how the choice > is made. > > * Undefined behaviour > > Behaviour, upon use of a nonportable or erroneous program construct of > erroneous data, for which this document imposes no requirements. > > * Unspecified behaviour > > Behaviour, that results from the use of an unspecified value, or other > behaviour upon which this document provides two or more possibilities > and imposes no further requirements on which is chosen in any instance. > """ > > IB means the standard gives certain options, and the implementation > documents which choices are made. That is completely different from > giving the implementation free reign. For example, right-shift of > negative integers gives an implementation-defined value - the > implementation can say it always gives the value 42, if it documents it, > but it is not allowed to say it causes a call to abort() or prints out a > run-time error message. > >> >>> The big disadvantage of making something like this "IB" is not that >>> the compiler implementers need to document their handling, but that >>> they need to have a specification for it and stick to that - users >>> must be able to rely on IB being consistent. >> >> Yes, but it allows that behavior to be anything the implementer >> chooses, including doing different things for different situations. >> The implementer has written some code to handle it. AFAICT the only >> difference is that IB requires the implementer document that code. > > No. See above. > >> >>> Different types of handling for hitting "unreachable()" can include >>> compiler optimisation on the assumption that it is never reached, >>> generating a target "trap" instruction, generating a "breakpoint" >>> when debugging, printing out an error message and terminating, >>> calling a user-defined function that sends an angry email to the >>> developer, and tracking all possible code flows at build time and >>> giving a compiler warning if it can, in fact, be reached. >> >> Absolutely agreed, and perhaps other choices as well. :-) And perhaps >> even different choices depending upon the specifics of the code around >> it. ID doesn't preclude any choices here. >> > > See above. > >>> Some users will prefer one method, others will prefer a different >>> one, and many will change depending on what they are doing. >> >> Sure. And making the implementer document their implementation would >> give the user a basis to choose whether to use that capability in a >> particular situation, or indeed perhaps (though unlikely) choose which >> compiler implementation to use. >> >>> Crucially, compilers may change what they support over time. A >>> compiler cannot document "IB" as "depending on flags, this might be >>> treated as UB, or give a trap, or perhaps do something else in the >>> future". But it /can/ do exactly that if the standards say it is "UB". >> >> I don't see why IB can't be dependent on flags. In fact that might be >> useful. The compiler already does something. Just document what it >> does. And as for future choices, nothing in IB prevents future >> changes, as long as they are documented. > > See above. > > I think we mostly agree on what we would like compiler implementations > to do, at least in some cases (I am not sure if you like the "anything > can happen" case of the compiler assuming unreachable() is never hit). > But what you want here is only achievable if the standard says it is UB, > not if the standard says it is IB. It is obvious that you are right; the the existing choices as documented in the standard and your post above (thanks for that) don't permit what I want. I apologize for not recognizing that up front. But I maintain that there should be a category that essentially says "You can do what you want, but you must document what you did." Furthermore, if such a choice existed, most instances of undefined should be "reclassified" into that new choice. I think that would aid programmers understanding. -- - Stephen Fuld (e-mail address disguised to prevent spam)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-23 21:24 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1191923$2287j$1@dont-email.me> |
| In reply to | #118157 |
On 23/09/2026 20:20, Stephen Fuld wrote: > On 9/23/2026 9:24 AM, David Brown wrote: >> I think we mostly agree on what we would like compiler implementations >> to do, at least in some cases (I am not sure if you like the "anything >> can happen" case of the compiler assuming unreachable() is never hit). >> But what you want here is only achievable if the standard says it is >> UB, not if the standard says it is IB. > > It is obvious that you are right; the the existing choices as documented > in the standard and your post above (thanks for that) don't permit what > I want. I apologize for not recognizing that up front. No problem - you are not the first person to miss that detail about what "implementation-defined behaviour" means in the C standards! > But I maintain > that there should be a category that essentially says "You can do what > you want, but you must document what you did." Furthermore, if such a > choice existed, most instances of undefined should be "reclassified" > into that new choice. I think that would aid programmers understanding. > I can appreciate that desire. But I suspect it would be very difficult to specify exactly what is meant here - the wording would perhaps end up too vague to be appropriate for an ISO language standard. It is also important to remember that everything that is not given an explicit definition in the C standards is "undefined behaviour" by omission. UB is not just the things the things that are explicitly marked as UB in their descriptions: """ If a ‘‘shall’’ or ‘‘shall not’’ requirement that appears outside of a constraint is violated, the behavior is undefined. Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’. """ It might, however, be possible to add footnotes to particular cases of UB with suggestions about how implementations might implement things or treat the UB. There is a move towards a concept of "erroneous behaviour" - this has been introduced in C++26, and will no doubt become part of the C standards at some point. This occurs, for example, when you try to use the value of an uninitialised local variable. It can, but does not have to, lead to a termination of the program and a diagnostic message - but AFAIUI it does not allow "time travelling" optimisations. It will not be appropriate for all types of UB - only in some specific cases can the compiler limit how badly things can go wrong in the face of UB. Annex L of the C standards distinguishes between "bounded undefined behaviour" and "critical undefined behaviour", where "bounded UB" does not do any stores (or volatile reads) outside of what is intended. (So signed integer overflow would be bounded UB, while writing beyond the end of an array would be critical UB.) In practice, AFAIK no compiler has tried to implement this and it has been fairly universally ignored. It is almost certainly too simplistic, as lots of apparently bounded UB could quickly lead to critical UB.
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-02 04:10 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119nar5$2rqdj$1@paganini.bofh.team> |
| In reply to | #118157 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>
> It is obvious that you are right; the the existing choices as documented
> in the standard and your post above (thanks for that) don't permit what
> I want. I apologize for not recognizing that up front. But I maintain
> that there should be a category that essentially says "You can do what
> you want, but you must document what you did." Furthermore, if such a
> choice existed, most instances of undefined should be "reclassified"
> into that new choice. I think that would aid programmers understanding.
In case of gcc 'ureachable()' can be given simple definition:
optimizer will assume that 'ureachable()' will never be
executed and do program transformations based on that knowledge.
Consder the following program fragment:
void foo1(int i) {
if (i < 0) {
unreachable();
}
foo2(i);
}
void foo2(int i) {
if (i < 0) {
foo3(i);
} else {
foo4(i);
}
}
In foo1 compiler could infer that 'i >= 0'. It could also inline
'foo2' into 'foo1'. After inlining it could infer that 'foo4'
will be called. So compiler could transform 'foo1' into
void foo1(int i) {
foo4(i);
}
If ever 'foo1' gets called with negative argument you would get
call to 'foo4' with negative argument.
Some people have mental model that C is compiled on statement by
statement basis. In compiler that is doing simple statement by
statement compilation 'if' in 'foo2' would prevent call to
'foo4' with negative argument. If compiler simply replaced
'unreachable()' by a trap instruction, then program would
trap in ;foo1'. But undefined behaviour opens essentially
unlimied possibilites for program transformation, based on
surrouding code.
BTW: I can image code using a macro
#define ASSERT_FACT(x) {if (x) unreachable();}
and codebase sprinkled with statements like:
ASSERT_FACT(i >= 0 && i < 100)
So 'unreachable()' essentially allows passing arbitrary assertions
to the compiler.
Let me add that given enough facts compiler should be able to
prove that all of them are true. It would be nice to have an
option so that compiler warns if it can not prove that some
'unreachable()' is really unreachable.
And note that false statement implies everthing, so if your
'unreachable()' is wrong then there are unlimited possibilities
for unexpected behaviour.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-10-02 10:05 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119nol7$1tfcv$1@dont-email.me> |
| In reply to | #118380 |
On 02/10/2026 06:10, Waldek Hebisch wrote:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>
>> It is obvious that you are right; the the existing choices as documented
>> in the standard and your post above (thanks for that) don't permit what
>> I want. I apologize for not recognizing that up front. But I maintain
>> that there should be a category that essentially says "You can do what
>> you want, but you must document what you did." Furthermore, if such a
>> choice existed, most instances of undefined should be "reclassified"
>> into that new choice. I think that would aid programmers understanding.
>
> In case of gcc 'ureachable()' can be given simple definition:
> optimizer will assume that 'ureachable()' will never be
> executed and do program transformations based on that knowledge.
>
Yes.
That is equivalent to saying that if the execution reaches
"unreachable()", the behaviour is undefined. In C, it is the same
thing. (Some people don't seem to like that, and think that "undefined
behaviour" should really mean "something vague and nebulous - I can't
explain it to other people, never mind to a compiler, but I am sure I
know what I mean".)
In gcc and clang, the function "unreachable()" is the same as
__builtin_unreachable(), and is translated directly by the front-end
into the "UB" code in the internal intermediary language of the compiler.
> Consder the following program fragment:
>
> void foo1(int i) {
> if (i < 0) {
> unreachable();
> }
> foo2(i);
> }
>
> void foo2(int i) {
> if (i < 0) {
> foo3(i);
> } else {
> foo4(i);
> }
> }
>
> In foo1 compiler could infer that 'i >= 0'. It could also inline
> 'foo2' into 'foo1'. After inlining it could infer that 'foo4'
> will be called. So compiler could transform 'foo1' into
>
> void foo1(int i) {
> foo4(i);
> }
>
> If ever 'foo1' gets called with negative argument you would get
> call to 'foo4' with negative argument.
Yes, that is exactly the kind of thing "unreachable()" is useful for.
>
> Some people have mental model that C is compiled on statement by
> statement basis. In compiler that is doing simple statement by
> statement compilation 'if' in 'foo2' would prevent call to
> 'foo4' with negative argument. If compiler simply replaced
> 'unreachable()' by a trap instruction, then program would
> trap in ;foo1'. But undefined behaviour opens essentially
> unlimied possibilites for program transformation, based on
> surrouding code.
I think it is quite common to wrap "unreachable()" in a macro so that
you can quickly make such a change before rebuilding your code.
Something like :
#ifdef DEBUGGING
#define Unreachable() __builtin_trap()
#else
#define Unreachable() unreachable()
#endif
>
> BTW: I can image code using a macro
>
> #define ASSERT_FACT(x) {if (x) unreachable();}
Or maybe even :
#define ASSERT_FACT(x) {if (!(x)) unreachable();}
Again, support for compile-time choices of run-time checks can be
useful. And you can get a compile-time error if the compiler is able to
see that the asserted "fact" is never true.
extern void __attribute__((error("Alternative fact asserted")))
assertFactFailed(void);
#define Assert_fact(x) \
do { \
if (__builtin_constant_p(!(x))) { \
if (!(x)) { \
assertFactFailed(); \
} \
} \
#ifdef DEBUGGING
if (!(x)) __builtin_trap(); \
#else
if (!(x)) __builtin_unreachable(); \
#endif
} while (0)
>
> and codebase sprinkled with statements like:
>
> ASSERT_FACT(i >= 0 && i < 100)
>
> So 'unreachable()' essentially allows passing arbitrary assertions
> to the compiler.
C++23 also has the [[assume(x)]] attribute doing exactly that, but it
has not made it into C as yet.
>
> Let me add that given enough facts compiler should be able to
> prove that all of them are true. It would be nice to have an
> option so that compiler warns if it can not prove that some
> 'unreachable()' is really unreachable.
>
I disagree on that one - or at least, I am very sceptical. You add an
"unreachable()" to the code precisely because you know more than the
compiler can realistically know. If the compiler can figure out that
"(i >= 0 && i < 100)", then there would be no need to tell it.
But I suppose you might still use it to help inform other programmers,
or to silence some warnings (like missing return values on code paths
that are never reached).
extern void __attribute__((error("Alternative fact confirmed")))
confirmIncorrectFact(void);
extern void __attribute__((error("Fact not confirmed")))
confirmFactFailed(void);
#define Confirm_fact(x) \
do { \
if (__builtin_constant_p(!(x))) { \
if (!(x)) { \
confirmIncorrectFact(); \
} \
} else { \
confirmFactFailed(); \
} \
} while (0)
Note that whether or not the compiler can confirm a claimed fact depends
on things like optimisation flags - that makes it all a bit fragile.
But you might find use for it.
(Of course __builtin_constant_p() is not portable beyond gcc, clang, and
perhaps a few other compilers.)
> And note that false statement implies everthing, so if your
> 'unreachable()' is wrong then there are unlimited possibilities
> for unexpected behaviour.
>
Yes.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-10-02 22:04 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <867bjznzmc.fsf@linuxsc.com> |
| In reply to | #118380 |
antispam@fricas.org (Waldek Hebisch) writes:
> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>
>> It is obvious that you are right; the the existing choices as
>> documented in the standard and your post above (thanks for that)
>> don't permit what I want. I apologize for not recognizing that up
>> front. But I maintain that there should be a category that
>> essentially says "You can do what you want, but you must document
>> what you did." Furthermore, if such a choice existed, most
>> instances of undefined should be "reclassified" into that new
>> choice. I think that would aid programmers understanding.
>
> In case of gcc 'ureachable()' can be given simple definition:
> optimizer will assume that 'ureachable()' will never be
> executed and do program transformations based on that knowledge.
>
> Consder the following program fragment:
>
> void foo1(int i) {
> if (i < 0) {
> unreachable();
> }
> foo2(i);
> }
>
> void foo2(int i) {
> if (i < 0) {
> foo3(i);
> } else {
> foo4(i);
> }
> }
>
> In foo1 compiler could infer that 'i >= 0'. It could also inline
> 'foo2' into 'foo1'. After inlining it could infer that 'foo4'
> will be called. So compiler could transform 'foo1' into
>
> void foo1(int i) {
> foo4(i);
> }
>
> If ever 'foo1' gets called with negative argument you would get
> call to 'foo4' with negative argument.
>
> Some people have mental model that C is compiled on statement by
> statement basis. In compiler that is doing simple statement by
> statement compilation 'if' in 'foo2' would prevent call to
> 'foo4' with negative argument. If compiler simply replaced
> 'unreachable()' by a trap instruction, then program would
> trap in ;foo1'. But undefined behaviour opens essentially
> unlimied possibilites for program transformation, based on
> surrouding code.
>
> BTW: I can image code using a macro
>
> #define ASSERT_FACT(x) {if (x) unreachable();}
>
> and codebase sprinkled with statements like:
>
> ASSERT_FACT(i >= 0 && i < 100)
>
> So 'unreachable()' essentially allows passing arbitrary assertions
> to the compiler.
>
> Let me add that given enough facts compiler should be able to
> prove that all of them are true. It would be nice to have an
> option so that compiler warns if it can not prove that some
> 'unreachable()' is really unreachable.
>
> And note that false statement implies everthing, so if your
> 'unreachable()' is wrong then there are unlimited possibilities
> for unexpected behaviour.
How is this reasoning affected by the change in definition of
undefined behavior in C23 (as compared for example with the
definitions in C11 or C99)?
[toc] | [prev] | [next] | [standalone]
| From | antispam@fricas.org (Waldek Hebisch) |
|---|---|
| Date | 2026-10-03 13:13 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119qv1s$389at$1@paganini.bofh.team> |
| In reply to | #118415 |
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> antispam@fricas.org (Waldek Hebisch) writes:
>
>> Stephen Fuld <sfuld@alumni.cmu.edu.invalid> wrote:
>>
>>> It is obvious that you are right; the the existing choices as
>>> documented in the standard and your post above (thanks for that)
>>> don't permit what I want. I apologize for not recognizing that up
>>> front. But I maintain that there should be a category that
>>> essentially says "You can do what you want, but you must document
>>> what you did." Furthermore, if such a choice existed, most
>>> instances of undefined should be "reclassified" into that new
>>> choice. I think that would aid programmers understanding.
>>
>> In case of gcc 'ureachable()' can be given simple definition:
>> optimizer will assume that 'ureachable()' will never be
>> executed and do program transformations based on that knowledge.
>>
>> Consder the following program fragment:
>>
>> void foo1(int i) {
>> if (i < 0) {
>> unreachable();
>> }
>> foo2(i);
>> }
>>
>> void foo2(int i) {
>> if (i < 0) {
>> foo3(i);
>> } else {
>> foo4(i);
>> }
>> }
>>
>> In foo1 compiler could infer that 'i >= 0'. It could also inline
>> 'foo2' into 'foo1'. After inlining it could infer that 'foo4'
>> will be called. So compiler could transform 'foo1' into
>>
>> void foo1(int i) {
>> foo4(i);
>> }
>>
>> If ever 'foo1' gets called with negative argument you would get
>> call to 'foo4' with negative argument.
>>
>> Some people have mental model that C is compiled on statement by
>> statement basis. In compiler that is doing simple statement by
>> statement compilation 'if' in 'foo2' would prevent call to
>> 'foo4' with negative argument. If compiler simply replaced
>> 'unreachable()' by a trap instruction, then program would
>> trap in ;foo1'. But undefined behaviour opens essentially
>> unlimied possibilites for program transformation, based on
>> surrouding code.
>>
>> BTW: I can image code using a macro
>>
>> #define ASSERT_FACT(x) {if (x) unreachable();}
>>
>> and codebase sprinkled with statements like:
>>
>> ASSERT_FACT(i >= 0 && i < 100)
>>
>> So 'unreachable()' essentially allows passing arbitrary assertions
>> to the compiler.
>>
>> Let me add that given enough facts compiler should be able to
>> prove that all of them are true. It would be nice to have an
>> option so that compiler warns if it can not prove that some
>> 'unreachable()' is really unreachable.
>>
>> And note that false statement implies everthing, so if your
>> 'unreachable()' is wrong then there are unlimited possibilities
>> for unexpected behaviour.
>
> How is this reasoning affected by the change in definition of
> undefined behavior in C23 (as compared for example with the
> definitions in C11 or C99)?
I am not aware of any change that would affect reasoning above.
AFAICS wording defining undefined behaviour is essentially the
same. But there are many scattered changes mentioning undefined
behaviour, so I may have missed something important. Still,
the reasong above is valid even with quite limited definition
of undefined behaviour, namely that up to the point of
encountering 'unreachable()' observable behaviour agrees with
abstract machine. Once 'unreachable()' is encountered,
behaviour of abstract machine is no longer defined, so
program may continue doing anything. And if 'unreachable()'
is not encountered, then propagating conditional info is
valid. Of course, time travel gives additional possibilities
for optimization, but the example above respects casuality.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2026-09-24 11:56 +0000 |
| Subject | Re: Optimization by programmers |
| Message-ID | <119334k$2l7jh$1@dont-email.me> |
| In reply to | #118154 |
David Brown <david.brown@hesbynett.no> schrieb:
> The "something" that they say is "If control flow reaches the point of
> the __builtin_unreachable, the program is undefined." That's the
> documentation in the gcc manual, along with some examples and use-cases.
This has important (well, to compiler developers) use cases, for
generating test cases. Grabbing a random example off bugzilla,
from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126048 :
int src(int v1_u8) {
if (!((1 <= v1_u8) && (v1_u8 <= 16))) __builtin_unreachable();
int i0_u8 = v1_u8 << v1_u8;
int i1_u8 = i0_u8 / v1_u8;
return i1_u8;
}
The specific information used here is "This cannot happen, so
optimize based on the knowledge that this is the case". It would
be possible to infer the same information from other method, but
this is quite convenient.
--
This USENET posting was made without artificial intelligence,
artificial impertinence, artificial arrogance, artificial stupidity,
artificial flavorings or artificial colorants.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-09-24 16:35 +0200 |
| Subject | Re: Optimization by programmers |
| Message-ID | <1193cf9$2opi0$1@dont-email.me> |
| In reply to | #118168 |
On 24/09/2026 13:56, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>
>> The "something" that they say is "If control flow reaches the point of
>> the __builtin_unreachable, the program is undefined." That's the
>> documentation in the gcc manual, along with some examples and use-cases.
>
> This has important (well, to compiler developers) use cases, for
> generating test cases. Grabbing a random example off bugzilla,
> from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126048 :
>
> int src(int v1_u8) {
> if (!((1 <= v1_u8) && (v1_u8 <= 16))) __builtin_unreachable();
> int i0_u8 = v1_u8 << v1_u8;
> int i1_u8 = i0_u8 / v1_u8;
> return i1_u8;
> }
>
> The specific information used here is "This cannot happen, so
> optimize based on the knowledge that this is the case". It would
> be possible to infer the same information from other method, but
> this is quite convenient.
>
This kind of "if (!XX) __builtin_unreachable();" is a common pattern.
You can also express basically the same thing as [[gnu::assume(XX)]],
but there can be slight differences in the kind of optimisation or
static error check effects you get as they are handled in different
passes of gcc.
I have used this in my own code, wrapped in a macro so that it is easy
to swap between checking for fault-finding and assuming for
optimisation. But you might use :
if ((i < 1) || (i > 2)) __builtin_unreachable();
switch (i) {
case 1 : ...
case 2 : ...
}
as an alternative to having a default case with __builtin_unreachable().
Either of these could be seen as more symmetric than :
if (i == 1) {
...
} else {
...
}
It can also be useful for static error checking. For switches,
enumeration types and "-Wswitch-enum" can be useful to ensure that if
you add another identifier to an enumeration and you have a switch using
the enumeration, you get a warning if you've forgotten to add the new
identifier to the switch. But sometimes that can be a bit more than you
want, and lead to false positives. An alternative setup is :
[[gnu::error("Should never happen"), noreturn]]
void should_never_get_here() ;
const int biggest_i = 2; // Or constexpr for C23
int foo(int i) {
if ((i < 1) || (i > biggest_i)) __builtin_unreachable();
[[gnu::assume((i >= 1) && (i <= biggest_i))]];
switch (i) {
case 1 : return 100;
case 2 : return 200;
}
should_never_get_here();
}
The "if (XX) __builtin_unreachable();" or "[[gnu::assume(XX)]];" lines
(only one is needed) put compile-time limits on the value of "i" that
the function expects. If you later decide that "i" can be as big as 3,
your switch needs to be changed to match - or else the code will try to
call "should_never_get_here()". If the compiler can't see that the code
flow could never reach that "function", and generates a call to it, you
get a compile-time error. Of course it is still your responsibility to
make sure "foo" is only called with an appropriate "i", but it adds an
extra compile-time safety check and documents your assumptions in the code.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-09-23 07:47 -0700 |
| Subject | Re: Optimization by programmers |
| Message-ID | <86pky4rpmb.fsf@linuxsc.com> |
| In reply to | #118135 |
Stephen Fuld <sfuld@alumni.cmu.edu.invalid> writes: > On 9/22/2026 5:32 AM, David Brown wrote: [...] >> And note that in C23 the macro "unreachable()" was added with the >> sole semantics being "If a macro invocation unreachable() is >> reached during execution, the behavior is undefined" and "The >> program execution shall not reach such an invocation". > > I don't have a problem with the inclusion of "unreachable()", but > can you give a possible rationale for making its behavior > "undefined" as opposed to say "implementation defined"? Yes, it > would make the compiler implementers do some work to document > whatever they decided to do, but are there any other reasons? The short answer is that being implementation-defined is too limiting. A construct having implementation-defined behavior cannot do "just anything"; the C standard must specify what behavior choices are possible. Any fixed set of choices might rule out what an implementation would like to do. So the only way to allow implementations to do whatever they choose is to have the behavior be undefined.
[toc] | [prev] | [next] | [standalone]
Page 11 of 24 — ← Prev page 1 … 9 10 [11] 12 13 … 24 Next page →
Back to top | Article view | comp.arch
csiph-web