Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #400344 > unrolled thread
| Started by | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| First post | 2026-07-22 01:38 +0200 |
| Last post | 2026-07-23 11:18 +0200 |
| Articles | 20 on this page of 184 — 20 participants |
Back to article view | Back to comp.lang.c
Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 01:38 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 17:26 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 01:50 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-21 20:25 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-22 17:37 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-22 13:26 -0700
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-22 07:33 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-22 10:41 +0200
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-22 18:08 -0500
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-23 10:31 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:31 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 14:48 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-23 15:11 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 09:23 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 03:14 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-24 14:56 +0000
Re: Prioritize Performance over Correctness antispam@fricas.org (Waldek Hebisch) - 2026-07-25 16:30 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 09:33 -0400
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 00:22 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 12:58 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:37 -0500
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-27 17:13 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 15:17 -0700
Re: Prioritize Performance over Correctness scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 01:18 +0000
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:40 +0800
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:18 +0000
Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 22:48 +0800
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-28 15:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 23:30 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 19:08 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:08 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:15 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:26 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 06:41 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:23 +0000
Picture of Organicks' book Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:01 +0800
Re: Picture of Organicks' book cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-29 13:46 +0000
Re: Picture of Organicks' book R Kym Horsell <kymhorsell@gmail.com> - 2026-07-29 16:54 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-29 23:22 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-15 15:55 -0700
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 18:58 +0000
Re: Multics( Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:10 +0800
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 22:20 +0000
Re: Multics( Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-07-29 14:44 +0000
Re: Multics( Re: Prioritize Performance over Correctness) cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-30 02:08 +0000
Re: Prioritize Performance over Correctness Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-08-16 07:59 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-27 17:59 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 15:42 +0800
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 03:22 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 19:21 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 13:02 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 20:18 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-28 14:17 +0100
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-28 16:02 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 16:45 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 12:03 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 19:32 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 13:42 +0100
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 20:49 +0800
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-29 16:01 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 12:53 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-31 14:21 -0400
Re: Prioritize Performance over Correctness bart <bc@freeuk.com> - 2026-07-31 20:07 +0100
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-31 13:00 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-01 02:34 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 16:08 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 23:28 +0000
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:22 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:51 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:32 -0400
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-28 14:20 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-28 13:54 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:00 +0800
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:25 -0400
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:55 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 20:31 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-28 21:26 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 14:57 -0700
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-29 15:33 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 16:22 -0700
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-07-30 07:40 +0100
Re: Prioritize Correctness over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 06:48 +0000
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:50 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:54 -0700
Re: Prioritize Correctness over Performance James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 08:24 -0400
Re: Prioritize Correctness over Performance Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:40 -0700
Re: Prioritize Correctness over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:39 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-30 06:44 -0400
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:00 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 14:38 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-30 21:53 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 15:10 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:40 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-07-31 02:43 +0000
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:44 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-30 19:58 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-01 01:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-02 23:14 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-02 14:37 -0700
Re: Prioritize Performance over Correctness Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-02 22:51 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 16:43 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 12:03 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-03 23:49 +0000
Re: Prioritize Correctness Over Performance "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 19:35 -0700
MS-DOS memory models (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 08:08 +0800
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 10:16 +0200
Re: Prioritize Performance over Correctness Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-03 10:41 +0100
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 12:28 +0200
Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 19:23 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 14:01 +0200
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-03 22:52 +0800
Re: Malicious Computer Architecture David Brown <david.brown@hesbynett.no> - 2026-08-03 19:41 +0200
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:13 -0700
Re: Malicious Computer Architecture "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:10 -0700
Re: Malicious Computer Architecture (was: Re: Prioritize Performance over Correctness) scott@slp53.sl.home (Scott Lurndal) - 2026-08-03 14:29 +0000
Johnny Depp prevention [Windows 11 etc...] (Was: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:10 +0200
But how can you deploy. when its ROM? (Was: Johnny Depp prevention [Windows 11 etc...]) Mild Shock <janburse@fastmail.fm> - 2026-08-03 18:15 +0200
GPU Elasticity: Collective Communications Libraries (Was: But how can you deploy. when its ROM?) Mild Shock <janburse@fastmail.fm> - 2026-08-07 14:37 +0200
What are Flits and Phits? [Network on a Chip] (Re: GPU Elasticity: Collective Communications Libraries) Mild Shock <janburse@fastmail.fm> - 2026-08-07 18:07 +0200
Cristallina: Thank you for the Beam (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-09 21:22 +0200
Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:26 +0200
How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Mild Shock <janburse@fastmail.fm> - 2026-08-18 16:50 +0200
Re: How to shoot yourself in the foot (Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:24 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-19 03:21 +0800
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Aidan Kehoe <kehoea@parhasard.net> - 2026-08-18 21:13 +0100
Re: Loderunner Enemy AI better than SWI-Prolog? [Prolog Education Group] Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-18 22:49 +0000
The Mac Neo is a Budget Monster [GPU Channels] (Re: What are Flits and Phits? [Network on a Chip]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:27 +0200
The luminaries of duct-tape engineering [Sweeney and Torvald] (Was: The Mac Neo is a Budget Monster [GPU Channels]) Mild Shock <janburse@fastmail.fm> - 2026-08-11 16:51 +0200
Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-03 19:51 +0100
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 00:22 +0800
Re: Malicious Computer Architecture Richard Harnden <richard.nospam@gmail.invalid> - 2026-08-04 19:10 +0100
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-05 03:21 +0800
Re: Malicious Computer Architecture Kaz Kylheku <046-301-5902@kylheku.com> - 2026-08-06 21:55 +0000
Re: Malicious Computer Architecture Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-08-07 06:31 +0800
Re: Malicious Computer Architecture Aidan Kehoe <kehoea@parhasard.net> - 2026-08-06 23:01 +0100
A Case for Impurity: The Applied Pi Calculus (Re: Malicious Computer Architecture) Mild Shock <janburse@fastmail.fm> - 2026-08-04 14:58 +0200
The Sandcastle of Paul Taraus Interactors (Re: A Case for Impurity: The Applied Pi Calculus) Mild Shock <janburse@fastmail.fm> - 2026-08-04 15:10 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 05:34 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:04 -0700
Re: Prioritize Correctness Over Performance Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-08-04 00:52 +0000
Re: Prioritize Correctness Over Performance scott@slp53.sl.home (Scott Lurndal) - 2026-08-04 14:22 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 05:25 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-03 15:10 +0200
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-08-03 13:16 -0700
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-08-03 20:29 -0400
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-03 17:55 -0700
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-08-04 09:12 +0200
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-08-02 19:01 -0700
Re: Prioritize Performance over Correctness cross@spitfire.i.gajendra.net (Dan Cross) - 2026-08-03 19:59 +0000
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-30 03:50 -0700
Re: Prioritize Performance over Correctness "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-07-29 15:09 -0700
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-28 08:14 +0800
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 05:54 +0800
Re: Prioritize Performance over Correctness steveo@panix.com (Steven M. O'Neill) - 2026-07-31 20:34 +0000
Re: Prioritize Performance over Correctness James Kuyper <jameskuyper@alumni.caltech.edu> - 2026-07-28 19:40 -0400
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-27 15:36 -0500
Re: Prioritize Performance over Correctness Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-29 04:56 +0800
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-24 14:47 +0200
Re: Prioritize Performance over Correctness David Brown <david.brown@hesbynett.no> - 2026-07-24 16:27 +0200
Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 00:52 +0800
Re: Resources for Amateur Compiler Writers bart <bc@freeuk.com> - 2026-07-24 23:08 +0100
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-24 18:50 -0500
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 01:54 +0000
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:20 +0800
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 07:24 +0000
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:30 +0800
Re: Resources for Amateur Compiler Writers David Brown <david.brown@hesbynett.no> - 2026-07-25 10:37 +0200
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-27 00:35 +0800
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-26 12:39 -0500
Re: Resources for Amateur Compiler Writers bart <bc@freeuk.com> - 2026-07-26 22:27 +0100
Re: Resources for Amateur Compiler Writers BGB <cr88192@gmail.com> - 2026-07-26 18:02 -0500
Re: Resources for Amateur Compiler Writers Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-07-25 22:32 +0000
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-25 15:58 -0700
Re: Resources for Amateur Compiler Writers David Brown <david.brown@hesbynett.no> - 2026-07-25 10:23 +0200
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 16:29 -0700
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-25 15:25 +0800
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-25 15:33 -0700
Re: Resources for Amateur Compiler Writers Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-07-27 00:38 +0800
Re: Resources for Amateur Compiler Writers Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-26 17:06 -0700
Re: Resources for Amateur Compiler Writers Cóilín Nioclásín Glostéir <thanks-to@Taf.com> - 2026-07-26 17:03 +0000
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-24 16:50 -0500
Re: Prioritize Performance over Correctness Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-07-24 16:13 -0700
Re: Prioritize Performance over Correctness BGB <cr88192@gmail.com> - 2026-07-26 15:26 -0500
Re: Prioritize Performance over Correctness Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-07-23 11:18 +0200
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-24 23:08 +0100 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1140npe$10v0o$1@dont-email.me> |
| In reply to | #400391 |
On 24/07/2026 17:52, Johann 'Myrkraverk' Oskarsson wrote:
> On 24/07/2026 8:47 PM, Janis Papanagnou wrote:
>> On 2026-07-23 23:31, Keith Thompson wrote:
>
>>>
>>> Certainly a warning would be nice. The problem is that unexpected
>>> optimizations in the presence of undefined behavior don't always occur
>>> because the compiler *knows* that the behavior is undefined.
>>
>> This thought or reasoning sounds completely perverted. - If the
>> compiler *knows* that there's undefined behavior (that may lead
>> to non-equivalent (=illegitimate) [dangerous] transformations!)
>> a warning (or error message) should be *mandated* in any case!
>> Without such a notice any "optimizations" (based on bizarre and
>> hazardous assumptions) should never be performed! - Certainly a
>> warning would not only be "nice" but should be mandated. - YMMV.
>>
>> It probably just boils down to the fact that the C-folks seem to
>> imply another meaning of "optimization", meaning more something
>> like "mutation of the code to something functionally different".
>>
>> Or, as it appear to me, that (with the knowledge of the inherent
>> problems to overcome the issues) accommodated to the situation.
>>
>> Given what "C" actually is (and what it can *not* become) I don't
>> think it makes sense to continue arguing about what I consider to
>> be just the crazy facts of ("C"-)reality.
>
> Sounds like you want to read /What every compiler writer should know
> about programmers/ by Anton Ertl, if you haven't already. Link at
>
> https://c9x.me/compile/bib/
>
This is an extract from that PDF:
-------------------------------
int d[16];
int SATD (void) {
int satd = 0, dd, k;
for (dd=d[k=0]; k<16; dd=d[++k]) {
satd += (dd < 0 ? -dd : dd);
}
return satd;
}
"This was “optimized” by a pre-release of gcc-4.8 into the following
infinite loop:
SATD:
.L2:
jmp .L2
What happened? The compiler assumed that no out-of-bounds access to d
would happen, and from that derived that k is at most 15 after the
access, so the following test k<16 can be “optimized” to 1 (true),
resulting in an endless loop. Then the compiler sees that the return is
now unreachable, that satd is dead, that dd is dead, and k is dead, and
optimizes the rest away."
-------------------------------
This is pretty crazy!
> and more for everyone who wants to write his own C compiler.
> What some people have done, including me, is to simply lose faith in
> the C ISO committee, and started to write our own C compilers.
Me too. But a big constraint is the language, and also existing
practice, if the aim is to be able to compile existing code.
Because 'big' compilers are gcc are lax by default, it means poor habits
are perpetuated over the years, and your compiler therefore needs to be
lax too, although at least you can make your own stricter by default
stricter.
By 'the language', I mean that C allows lots of things which in my own
systems language for example, that I maintain, would be impossible to
write as they are nonsensical.
With C, what I found bizarre was that it was easy to write a C program
where with one of these results when compiled:
* It passes with no errors
* It passes but with warnings (and still generates an executable)
* It fails with errors
All depending on which options have been chosen. Was the program correct
or not; who knows? I think here it is the language standard giving too
much scope to compilers, in part in order to be able to compile poor
quality legacy code.
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-07-24 18:50 -0500 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1140tup$12gs8$1@dont-email.me> |
| In reply to | #400393 |
On 7/24/2026 5:08 PM, bart wrote:
> On 24/07/2026 17:52, Johann 'Myrkraverk' Oskarsson wrote:
>> On 24/07/2026 8:47 PM, Janis Papanagnou wrote:
>>> On 2026-07-23 23:31, Keith Thompson wrote:
>>
>>>>
>>>> Certainly a warning would be nice. The problem is that unexpected
>>>> optimizations in the presence of undefined behavior don't always occur
>>>> because the compiler *knows* that the behavior is undefined.
>>>
>>> This thought or reasoning sounds completely perverted. - If the
>>> compiler *knows* that there's undefined behavior (that may lead
>>> to non-equivalent (=illegitimate) [dangerous] transformations!)
>>> a warning (or error message) should be *mandated* in any case!
>>> Without such a notice any "optimizations" (based on bizarre and
>>> hazardous assumptions) should never be performed! - Certainly a
>>> warning would not only be "nice" but should be mandated. - YMMV.
>>>
>>> It probably just boils down to the fact that the C-folks seem to
>>> imply another meaning of "optimization", meaning more something
>>> like "mutation of the code to something functionally different".
>>>
>>> Or, as it appear to me, that (with the knowledge of the inherent
>>> problems to overcome the issues) accommodated to the situation.
>>>
>>> Given what "C" actually is (and what it can *not* become) I don't
>>> think it makes sense to continue arguing about what I consider to
>>> be just the crazy facts of ("C"-)reality.
>>
>> Sounds like you want to read /What every compiler writer should know
>> about programmers/ by Anton Ertl, if you haven't already. Link at
>>
>> https://c9x.me/compile/bib/
>>
>
>
> This is an extract from that PDF:
>
> -------------------------------
> int d[16];
> int SATD (void) {
> int satd = 0, dd, k;
> for (dd=d[k=0]; k<16; dd=d[++k]) {
> satd += (dd < 0 ? -dd : dd);
> }
> return satd;
> }
>
> "This was “optimized” by a pre-release of gcc-4.8 into the following
> infinite loop:
>
> SATD:
> .L2:
> jmp .L2
>
> What happened? The compiler assumed that no out-of-bounds access to d
> would happen, and from that derived that k is at most 15 after the
> access, so the following test k<16 can be “optimized” to 1 (true),
> resulting in an endless loop. Then the compiler sees that the return is
> now unreachable, that satd is dead, that dd is dead, and k is dead, and
> optimizes the rest away."
>
> -------------------------------
>
> This is pretty crazy!
>
Yeah...
This sort of thing is a danger of performing high-level optimizations...
Ironically, I was getting mostly good results in my compiler not doing
any of these sorts of optimizations. But, it does depend some on the code.
Code that assumes high-level code-rewriting transformations will,
granted, not perform well...
>> and more for everyone who wants to write his own C compiler.
>
>> What some people have done, including me, is to simply lose faith in
>> the C ISO committee, and started to write our own C compilers.
>
> Me too. But a big constraint is the language, and also existing
> practice, if the aim is to be able to compile existing code.
>
> Because 'big' compilers are gcc are lax by default, it means poor habits
> are perpetuated over the years, and your compiler therefore needs to be
> lax too, although at least you can make your own stricter by default
> stricter.
>
> By 'the language', I mean that C allows lots of things which in my own
> systems language for example, that I maintain, would be impossible to
> write as they are nonsensical.
>
There are some things I would do different from C as well...
But, harder to bring enough merit over just using C, to justify the
added cost of it being "not C".
Like, in an area where I had one of my own languages (BS2) sharing
basically all of the compiler infrastructure, ABI, etc, with C (and
being able to import most BS2 features as C extensions), made it harder
to justify using my own language.
That said, there are things I might have done different in BS2 as well
in retrospect:
Making 'char' 16-bit (like Java and C#) was a mistake;
Should have leaned more towards C# syntax than Java syntax;
...
But, then it would have mostly been "kinda like C++, but different".
Part of this was because BS2 syntax had evolved partly from a later form
of BGBScript, which had started based on JavaScript and evolved in a
similar direction to ActionScript3 and Haxe; but with BS2 being a reboot
towards a Java-like syntax...
It is supported in BGBCC, mostly sharing pretty much everything with my
C compiler (both with produce native code for the same target ISAs, etc).
There was at one point to use the same basic stuff to implement a C++
like mode, but C++ was different enough (and added enough complexity of
its own) to mostly kill off this effort.
It does (in theory) support a C++ dialect partway between EC++ and C++97
in terms of feature-set:
Core is a single-inheritance object system with interfaces via abstract
base-classes;
Supports namespaces;
Some (not well tested) support for templates.
But, not really close enough...
Also there was some wonk as well:
Like in C#, classes and structs are treated as two different types of
thing; where classes are always treated internally as being "by-reference";
To mimic C++ style by-value classes, it essentially needs to clone
objects on assignment and "delete" them as they go out of scope, which
is "not very good" (though, the basic mechanism already exists, was used
for "alloca" and C99 style VLAs).
There are some other things I might want to change though:
Make BS2 classes structurally equivalent to COM interfaces;
Maybe devise a high-level way for inter-process COM handlers;
...
As-is, the BS2 classes don't match up exactly with COM interfaces, but
there could arguably be more merit to using the language if a COM object
could simply be cast to a class and used directly, or if a class object
could be exported as a COM object.
But, then there are still limits, for example, had thought "what if I
could export VFS interfaces from userland to kernel space via COM
interfaces?" but then ran into the issue that this would likely create
some difficult to resolve "paradox level" issues with the system design.
So, as-is, interfaces are still either strictly User->Kernel or
User->User, but Kernel->User can't currently be done (nor can any
recursive or re-entrant call paths).
Where, say, COM interfaces are usually expressed in C land sorta like:
struct IFoo_vt_s {
void *reserved1;
void *reserved2;
int (*Method1)(IFoo_vt **clz, int arg1);
int (*Method2)(IFoo_vt **clz, char *arg1);
...
};
IFoo_vt **obj;
(*obj)->Method1(obj, 42);
And, there might be some metit if, say:
__interface IFoo {
int Method1(int arg1);
int Method2(char *arg1);
};
Were structurally equivalent.
But, this isn't a hard limit, but possibly an eventual TODO.
Main difference being that the current implementation typically reserves
the first 4 VTable entries and uses a "thiscall" which passes the 'this'
pointer in a separate register rather than as the first argument.
> With C, what I found bizarre was that it was easy to write a C program
> where with one of these results when compiled:
>
> * It passes with no errors
> * It passes but with warnings (and still generates an executable)
> * It fails with errors
>
> All depending on which options have been chosen. Was the program correct
> or not; who knows? I think here it is the language standard giving too
> much scope to compilers, in part in order to be able to compile poor
> quality legacy code.
I would narrow the scope as well, but admittedly more in terms of trying
to move more of the "undefined behavior" into "defined behavior".
But, if one is like:
Integers are twos complement and little endian in memory;
Misaligned pointers are allowed;
Integers are wrap on overflow;
Signed right shift is sign-extending;
Programmers are free to cast and de-reference pointers however;
Required to work so long as the target is "knowable".
...
There may exist some who would balk as they are maintaining
implementations where these assumptions may fail.
One may be like, "but we have SIMD load/stores that don't work if the
pointer is misaligned...", but then one can be like, "figure out how to
infer whether or not the pointer is aligned before deciding on an
aligned-only SIMD load...".
Like, for example, I have an ISA where the 128-bit load instruction is
also aligned-only (*), but I am not going to use it as an excuse to
forbid "*(__int128 *)someptr", rather merely that the inability of the
compiler to prove alignment requires a fallback to less efficient
load/store in this case.
*: In a CPU design, it is easier to make it so that all of the
"non-maximum-sized" types are unaligned safe, but cost tradeoffs may
mean needing to make the largest loads/stores respect alignment constraints.
...
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-07-25 01:54 +0000 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1141514$14dqg$4@dont-email.me> |
| In reply to | #400393 |
On Fri, 24 Jul 2026 23:08:47 +0100, bart wrote:
> On 24/07/2026 17:52, Johann 'Myrkraverk' Oskarsson wrote:
>>
>> https://c9x.me/compile/bib/
>
> This is an extract from that PDF:
>
> -------------------------------
> int d[16];
> int SATD (void) {
> int satd = 0, dd, k;
> for (dd=d[k=0]; k<16; dd=d[++k]) {
> satd += (dd < 0 ? -dd : dd);
> }
> return satd;
> }
>
> "This was “optimized” by a pre-release of gcc-4.8 into the following
> infinite loop:
>
> SATD:
> .L2:
> jmp .L2
>
> What happened? The compiler assumed that no out-of-bounds access to
> d would happen, and from that derived that k is at most 15 after the
> access, so the following test k<16 can be “optimized” to 1 (true),
> resulting in an endless loop. Then the compiler sees that the return
> is now unreachable, that satd is dead, that dd is dead, and k is
> dead, and optimizes the rest away."
>
> -------------------------------
>
> This is pretty crazy!
Would you rather it segfaulted instead?
Because I can’t see any other reasonable interpretation of that code.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-25 15:20 +0800 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <XsZ8S.144528$TSTf.31728@fx03.ams4> |
| In reply to | #400397 |
On 25/07/2026 9:54 AM, Lawrence D’Oliveiro wrote:
> On Fri, 24 Jul 2026 23:08:47 +0100, bart wrote:
>
>> On 24/07/2026 17:52, Johann 'Myrkraverk' Oskarsson wrote:
>>>
>>> https://c9x.me/compile/bib/
>>
>> This is an extract from that PDF:
>>
>> -------------------------------
>> int d[16];
>> int SATD (void) {
>> int satd = 0, dd, k;
>> for (dd=d[k=0]; k<16; dd=d[++k]) {
>> satd += (dd < 0 ? -dd : dd);
>> }
>> return satd;
>> }
>>
>> "This was “optimized” by a pre-release of gcc-4.8 into the following
>> infinite loop:
>>
>> SATD:
>> .L2:
>> jmp .L2
>>
>> What happened? The compiler assumed that no out-of-bounds access to
>> d would happen, and from that derived that k is at most 15 after the
>> access, so the following test k<16 can be “optimized” to 1 (true),
>> resulting in an endless loop. Then the compiler sees that the return
>> is now unreachable, that satd is dead, that dd is dead, and k is
>> dead, and optimizes the rest away."
>>
>> -------------------------------
>>
>> This is pretty crazy!
>
> Would you rather it segfaulted instead?
>
> Because I can’t see any other reasonable interpretation of that code.
The code is perfectly reasonable. Did you forget globals are zero
initialized? d[] is a global, it has zeros.
satd is initialized to zero, and the for loop initializes dd and k.
I see no way for the loop to make an out of bound access at first
glance.
That said, I didn't step through the code. Is satd /saturated d/?
--
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-07-25 07:24 +0000 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1141obq$1akqt$1@dont-email.me> |
| In reply to | #400398 |
On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson wrote: > The code is perfectly reasonable. If the code were “perfectly reasonable”, then there would be a compiler bug. There isn’t.
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-25 15:30 +0800 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <5CZ8S.240792$Xz_7.35251@fx06.ams4> |
| In reply to | #400399 |
On 25/07/2026 3:24 PM, Lawrence D’Oliveiro wrote: > On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson > wrote: > >> The code is perfectly reasonable. > > If the code were “perfectly reasonable”, then there would be a > compiler bug. There isn’t. That's a simple matter of debate. I make the point it's a compiler bug. You don't, so you must be a member of the "big three" developer teams. Therefore all your opinions on my way of compiling C are completely invalid. -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-07-25 10:37 +0200 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1141skl$1bej1$2@dont-email.me> |
| In reply to | #400401 |
On 25/07/2026 09:30, Johann 'Myrkraverk' Oskarsson wrote: > On 25/07/2026 3:24 PM, Lawrence D’Oliveiro wrote: >> On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson >> wrote: >> >>> The code is perfectly reasonable. >> >> If the code were “perfectly reasonable”, then there would be a >> compiler bug. There isn’t. > > That's a simple matter of debate. I make the point it's a compiler > bug. You don't, so you must be a member of the "big three" developer > teams. Therefore all your opinions on my way of compiling C are > completely invalid. It is not a matter of debate - the code is buggy. But it's not entirely obvious that it is buggy - the folks who wrote the code were pretty good and experienced C programmers, and /they/ didn't notice the bug. Lawrence is not (AFAIK) a developer for the "big three" compiler groups, but perhaps he works in support for a big IT company - his answer was technically entirely correct, while being entirely unhelpful. If you look carefully at the code again, consider the final iteration - when k is 15 (the test "k < 16" still passes) there is the expression "dd = d[++k]". "k" is incremented to 16, and then we read "d[16]" to assign to "dd". But "d[16]" does not exist - the array "d" runs from "d[0]" to "d[15]". Attempting to read "d[16]" is an out-of-bounds access, and that's UB. It's a bug. So given that the input code has no defined behaviour, generated code cannot be wrong no matter what it does - there is nothing to compare it to for correctness. The compiler is has no bug. (Not here, anyway - gcc is not bug-free!) That does not mean the compiler is being as helpful a development tool as it could have been (the warning generated by gcc 4.9 and later is more useful). But it is worth noting that if compilers had done as the pre-release gcc 4.8 compiler did when the SPEC code was written, then the bug in the source would have been identified and fixed eons ago. Look at the following godbolt link, and compare the warning messages when the declaration of "d" is changed between "int d[16]" and "int d[17]". <https://godbolt.org/z/75WGof54G>
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-27 00:35 +0800 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <LHq9S.239269$OIh6.144784@fx13.ams4> |
| In reply to | #400403 |
On 25/07/2026 4:37 PM, David Brown wrote: > On 25/07/2026 09:30, Johann 'Myrkraverk' Oskarsson wrote: >> On 25/07/2026 3:24 PM, Lawrence D’Oliveiro wrote: >>> On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson >>> wrote: >>> >>>> The code is perfectly reasonable. >>> >>> If the code were “perfectly reasonable”, then there would be a >>> compiler bug. There isn’t. >> >> That's a simple matter of debate. I make the point it's a compiler >> bug. You don't, so you must be a member of the "big three" developer >> teams. Therefore all your opinions on my way of compiling C are >> completely invalid. > > It is not a matter of debate - the code is buggy. But it's not entirely > obvious that it is buggy - the folks who wrote the code were pretty good > and experienced C programmers, and /they/ didn't notice the bug. > Lawrence is not (AFAIK) a developer for the "big three" compiler groups, > but perhaps he works in support for a big IT company - his answer was > technically entirely correct, while being entirely unhelpful. Don't worry about Lawrence. I just told him to buy CorelDRAW in comp. unix.shell. He's being very stubborn about being unhelpful. I'm enjoying teasing him about it. He'll learn eventually that I don't care at all about his opinions about anything. > > > If you look carefully at the code again, consider the final iteration - > when k is 15 (the test "k < 16" still passes) there is the expression > "dd = d[++k]". "k" is incremented to 16, and then we read "d[16]" to > assign to "dd". But "d[16]" does not exist - the array "d" runs from > "d[0]" to "d[15]". Attempting to read "d[16]" is an out-of-bounds > access, and that's UB. It's a bug. Right, I did not notice that; thank you. I'll add it as a test case for my compiler. I'm still working on preliminaries, so it might take a year or two, or a decade before I'll show how I treat this code. Happy compiling! -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-07-26 12:39 -0500 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1145gvh$2ijto$1@dont-email.me> |
| In reply to | #400426 |
On 7/26/2026 11:35 AM, Johann 'Myrkraverk' Oskarsson wrote:
> On 25/07/2026 4:37 PM, David Brown wrote:
>> On 25/07/2026 09:30, Johann 'Myrkraverk' Oskarsson wrote:
>>> On 25/07/2026 3:24 PM, Lawrence D’Oliveiro wrote:
>>>> On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson
>>>> wrote:
>>>>
>>>>> The code is perfectly reasonable.
>>>>
>>>> If the code were “perfectly reasonable”, then there would be a
>>>> compiler bug. There isn’t.
>>>
>>> That's a simple matter of debate. I make the point it's a compiler
>>> bug. You don't, so you must be a member of the "big three" developer
>>> teams. Therefore all your opinions on my way of compiling C are
>>> completely invalid.
>>
>> It is not a matter of debate - the code is buggy. But it's not
>> entirely obvious that it is buggy - the folks who wrote the code were
>> pretty good and experienced C programmers, and /they/ didn't notice
>> the bug. Lawrence is not (AFAIK) a developer for the "big three"
>> compiler groups, but perhaps he works in support for a big IT company
>> - his answer was technically entirely correct, while being entirely
>> unhelpful.
>
> Don't worry about Lawrence. I just told him to buy CorelDRAW in comp.
> unix.shell. He's being very stubborn about being unhelpful. I'm
> enjoying teasing him about it. He'll learn eventually that I don't
> care at all about his opinions about anything.
>>
>>
>> If you look carefully at the code again, consider the final iteration
>> - when k is 15 (the test "k < 16" still passes) there is the
>> expression "dd = d[++k]". "k" is incremented to 16, and then we read
>> "d[16]" to assign to "dd". But "d[16]" does not exist - the array "d"
>> runs from "d[0]" to "d[15]". Attempting to read "d[16]" is an out-of-
>> bounds access, and that's UB. It's a bug.
>
> Right, I did not notice that; thank you. I'll add it as a test case
> for my compiler. I'm still working on preliminaries, so it might take
> a year or two, or a decade before I'll show how I treat this code.
>
Well, decided to see what my compiler would do...
So, to recap:
int d[16];
int SATD (void) {
int satd = 0, dd, k;
for (dd=d[k=0]; k<16; dd=d[++k]) {
satd += (dd < 0 ? -dd : dd);
}
return satd;
}
Gives:
SATD:
// tst_random1.c:2 int SATD (void) {
ADD RD0, RQ0, RD13
// tst_random1.c:4 for (dd=d[k=0]; k<16; dd=d[++k]) {
ADD RD0, RQ0, RD12
MOV d, RQ11
MOV.L (RQ11, 0), RD10
.L00800000:
MOV 16, RD11
BRGE.L RD11, RD12, .L00800002
BRGE.L R0, RD10, .L00800003
RSUBS.L RD10, 0, RQ11
ADD RQ11, RQ0, RQ17
BSR .L00800004, R0
.L00800003:
ADD RD10, RQ0, RQ17
.L00800004:
ADDS.L RD13, RQ17, RD13
ADDS.L RD12, 1, RD12
MOV d, RQ16
MOV.L (RQ16, RD12), RD10
BSR .L00800000, R0
.L00800002:
// tst_random1.c:6 }
ADDS.L RD13, RQ0, RD10
.L00C000F9:
JSR R1, 0, R0
Not exactly the way that is good to write ASM, just what my compiler
outputs when dumping ASM...
Decided not to really try to explain it, or what sort of ISA it is
aiming for.
Not the cleverest compiler around either, but gets the job done...
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2026-07-26 22:27 +0100 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1145u4s$2mqqi$1@dont-email.me> |
| In reply to | #400431 |
On 26/07/2026 18:39, BGB wrote:
> On 7/26/2026 11:35 AM, Johann 'Myrkraverk' Oskarsson wrote:
>> On 25/07/2026 4:37 PM, David Brown wrote:
>>> On 25/07/2026 09:30, Johann 'Myrkraverk' Oskarsson wrote:
>>>> On 25/07/2026 3:24 PM, Lawrence D’Oliveiro wrote:
>>>>> On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson
>>>>> wrote:
>>>>>
>>>>>> The code is perfectly reasonable.
>>>>>
>>>>> If the code were “perfectly reasonable”, then there would be a
>>>>> compiler bug. There isn’t.
>>>>
>>>> That's a simple matter of debate. I make the point it's a compiler
>>>> bug. You don't, so you must be a member of the "big three" developer
>>>> teams. Therefore all your opinions on my way of compiling C are
>>>> completely invalid.
>>>
>>> It is not a matter of debate - the code is buggy. But it's not
>>> entirely obvious that it is buggy - the folks who wrote the code were
>>> pretty good and experienced C programmers, and /they/ didn't notice
>>> the bug. Lawrence is not (AFAIK) a developer for the "big three"
>>> compiler groups, but perhaps he works in support for a big IT company
>>> - his answer was technically entirely correct, while being entirely
>>> unhelpful.
>>
>> Don't worry about Lawrence. I just told him to buy CorelDRAW in comp.
>> unix.shell. He's being very stubborn about being unhelpful. I'm
>> enjoying teasing him about it. He'll learn eventually that I don't
>> care at all about his opinions about anything.
>>>
>>>
>>> If you look carefully at the code again, consider the final iteration
>>> - when k is 15 (the test "k < 16" still passes) there is the
>>> expression "dd = d[++k]". "k" is incremented to 16, and then we read
>>> "d[16]" to assign to "dd". But "d[16]" does not exist - the array
>>> "d" runs from "d[0]" to "d[15]". Attempting to read "d[16]" is an
>>> out-of- bounds access, and that's UB. It's a bug.
>>
>> Right, I did not notice that; thank you. I'll add it as a test case
>> for my compiler. I'm still working on preliminaries, so it might take
>> a year or two, or a decade before I'll show how I treat this code.
>>
>
>
> Well, decided to see what my compiler would do...
>
> So, to recap:
> int d[16];
> int SATD (void) {
> int satd = 0, dd, k;
> for (dd=d[k=0]; k<16; dd=d[++k]) {
> satd += (dd < 0 ? -dd : dd);
> }
> return satd;
> }
>
> Gives:
>
> SATD:
> // tst_random1.c:2 int SATD (void) {
> ADD RD0, RQ0, RD13
> // tst_random1.c:4 for (dd=d[k=0]; k<16; dd=d[++k]) {
> ADD RD0, RQ0, RD12
> MOV d, RQ11
> MOV.L (RQ11, 0), RD10
> .L00800000:
> MOV 16, RD11
> BRGE.L RD11, RD12, .L00800002
> BRGE.L R0, RD10, .L00800003
> RSUBS.L RD10, 0, RQ11
> ADD RQ11, RQ0, RQ17
> BSR .L00800004, R0
> .L00800003:
> ADD RD10, RQ0, RQ17
> .L00800004:
> ADDS.L RD13, RQ17, RD13
> ADDS.L RD12, 1, RD12
> MOV d, RQ16
> MOV.L (RQ16, RD12), RD10
> BSR .L00800000, R0
> .L00800002:
> // tst_random1.c:6 }
> ADDS.L RD13, RQ0, RD10
> .L00C000F9:
> JSR R1, 0, R0
>
> Not exactly the way that is good to write ASM, just what my compiler
> outputs when dumping ASM...
>
>
> Decided not to really try to explain it, or what sort of ISA it is
> aiming for.
>
> Not the cleverest compiler around either, but gets the job done...
>
Your code is a lot shorter than mine: 18 executable instrs versus 31 for
mine which is for x64. Although 6 are to save/restore non-vol regs, and
2 for a stack-frame which doesn't appear to be needed.
It does nothing at all about trying to detect possible out-of-bounds errors.
gcc-O2 does it in 13, but -O3 is longer due to using SIMD and no looping.
However I then tried it in my systems language (an equivalent program)
and there it was only 22 instruction, shown below. More amenable
language features can help! Here also there is no out-of-bounds error.
SATD:: # (uses non-standard reg names: A/D = 32/64 bits)
R.satd = A3
R.dd = A4
R.k = A5
push D3
push D4
push D5
sub Dsp, 16
;---------------
xor R.satd, R.satd
xor A0, A0
mov R.k, A0
movsx D1, A0
lea D0, [d]
mov R.dd, [D0 + D1*4]
jmp L4
L5:
cmp R.dd, 0
jge L6
mov A0, R.dd
neg A0
jmp L7
L6:
mov A0, R.dd
L7:
add R.satd, A0
inc R.k
mov A0, R.k
movsx D1, A0
lea D0, [d]
mov R.dd, [D0 + D1*4]
L4:
cmp R.k, 16
jl L5
mov A0, R.satd
L1:
;---------------
add Dsp, 16
pop D5
pop D4
pop D3
ret
---------------------------
Version in my language (uses 64-bit ints and is 1-based):
---------------------------
[16]int d
func satd:int =
int sum:=0
for x in d do # iterates over values
sum +:= abs(x)
end
sum
end
---------------------------
t.satd:
R.sum = D3
R.av_1 = D4
R.x = D5
push R.sum
push R.av_1
push R.x
sub Dsp, 16 # this is again not needed! (Same backend)
;---------------
xor R.sum, R.sum
mov D0, 1
mov R.av_1, D0
L2:
mov R.x, [R.av_1*8 + t.d-8]
mov D0, R.x
cmp D0, 0
jge L5
neg D0
L5:
add R.sum, D0
inc R.av_1
cmp R.av_1, 16
jle L2
mov D0, R.sum
L1:
;---------------
add Dsp, 16
pop R.x
pop R.av_1
pop R.sum
ret
[toc] | [prev] | [next] | [standalone]
| From | BGB <cr88192@gmail.com> |
|---|---|
| Date | 2026-07-26 18:02 -0500 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <11463so$2p07d$1@dont-email.me> |
| In reply to | #400435 |
On 7/26/2026 4:27 PM, bart wrote:
> On 26/07/2026 18:39, BGB wrote:
>> On 7/26/2026 11:35 AM, Johann 'Myrkraverk' Oskarsson wrote:
>>> On 25/07/2026 4:37 PM, David Brown wrote:
>>>> On 25/07/2026 09:30, Johann 'Myrkraverk' Oskarsson wrote:
>>>>> On 25/07/2026 3:24 PM, Lawrence D’Oliveiro wrote:
>>>>>> On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson
>>>>>> wrote:
>>>>>>
>>>>>>> The code is perfectly reasonable.
>>>>>>
>>>>>> If the code were “perfectly reasonable”, then there would be a
>>>>>> compiler bug. There isn’t.
>>>>>
>>>>> That's a simple matter of debate. I make the point it's a compiler
>>>>> bug. You don't, so you must be a member of the "big three" developer
>>>>> teams. Therefore all your opinions on my way of compiling C are
>>>>> completely invalid.
>>>>
>>>> It is not a matter of debate - the code is buggy. But it's not
>>>> entirely obvious that it is buggy - the folks who wrote the code
>>>> were pretty good and experienced C programmers, and /they/ didn't
>>>> notice the bug. Lawrence is not (AFAIK) a developer for the "big
>>>> three" compiler groups, but perhaps he works in support for a big IT
>>>> company - his answer was technically entirely correct, while being
>>>> entirely unhelpful.
>>>
>>> Don't worry about Lawrence. I just told him to buy CorelDRAW in comp.
>>> unix.shell. He's being very stubborn about being unhelpful. I'm
>>> enjoying teasing him about it. He'll learn eventually that I don't
>>> care at all about his opinions about anything.
>>>>
>>>>
>>>> If you look carefully at the code again, consider the final
>>>> iteration - when k is 15 (the test "k < 16" still passes) there is
>>>> the expression "dd = d[++k]". "k" is incremented to 16, and then we
>>>> read "d[16]" to assign to "dd". But "d[16]" does not exist - the
>>>> array "d" runs from "d[0]" to "d[15]". Attempting to read "d[16]"
>>>> is an out-of- bounds access, and that's UB. It's a bug.
>>>
>>> Right, I did not notice that; thank you. I'll add it as a test case
>>> for my compiler. I'm still working on preliminaries, so it might take
>>> a year or two, or a decade before I'll show how I treat this code.
>>>
>>
>>
>> Well, decided to see what my compiler would do...
>>
>> So, to recap:
>> int d[16];
>> int SATD (void) {
>> int satd = 0, dd, k;
>> for (dd=d[k=0]; k<16; dd=d[++k]) {
>> satd += (dd < 0 ? -dd : dd);
>> }
>> return satd;
>> }
>>
>> Gives:
>>
>> SATD:
>> // tst_random1.c:2 int SATD (void) {
>> ADD RD0, RQ0, RD13
>> // tst_random1.c:4 for (dd=d[k=0]; k<16; dd=d[++k]) {
>> ADD RD0, RQ0, RD12
>> MOV d, RQ11
>> MOV.L (RQ11, 0), RD10
>> .L00800000:
>> MOV 16, RD11
>> BRGE.L RD11, RD12, .L00800002
>> BRGE.L R0, RD10, .L00800003
>> RSUBS.L RD10, 0, RQ11
>> ADD RQ11, RQ0, RQ17
>> BSR .L00800004, R0
>> .L00800003:
>> ADD RD10, RQ0, RQ17
>> .L00800004:
>> ADDS.L RD13, RQ17, RD13
>> ADDS.L RD12, 1, RD12
>> MOV d, RQ16
>> MOV.L (RQ16, RD12), RD10
>> BSR .L00800000, R0
>> .L00800002:
>> // tst_random1.c:6 }
>> ADDS.L RD13, RQ0, RD10
>> .L00C000F9:
>> JSR R1, 0, R0
>>
>> Not exactly the way that is good to write ASM, just what my compiler
>> outputs when dumping ASM...
>>
>>
>> Decided not to really try to explain it, or what sort of ISA it is
>> aiming for.
>>
>> Not the cleverest compiler around either, but gets the job done...
>>
>
> Your code is a lot shorter than mine: 18 executable instrs versus 31 for
> mine which is for x64. Although 6 are to save/restore non-vol regs, and
> 2 for a stack-frame which doesn't appear to be needed.
>
> It does nothing at all about trying to detect possible out-of-bounds
> errors.
>
My compiler also doesn't notice the out-of-bounds.
But, yeah, the code in question is for XG3, but the output for RV64G is
kinda similar in this case. Neither is standard RV ASM syntax.
In this case, compiler skips prolog/epilog because the function is a
leaf function and everything fits into the available scratch registers.
Decided to leave out a longer description, but in this case XG3 uses a
modified variant/hybrid of the LP64 and LP64D ABI rules.
The ABI is very different from that used by XG1 and XG2 (and is a major
reason none of the XG1/XG2 ASM code works with XG3).
Can't give an X86-64 example because BGBCC doesn't target these. Hasn't
usually been a good reason to target a platform that is already well
served by the existing compilers.
Arguably, there are more efficient ways it could have handled the ?:,
but making ?: more efficient is a long-standing TODO.
Like, say, in theory it could have done:
SUBS.L R0, R10, R11 //SUBW X11, X0, X10
MAX R10, R11, R17
Or:
SUBS.L R0, R10, R11
SLT R10, 0, R0
CSELT R11, R10, R17
Or:
...
But, alas...
So, say, hand-optimizing it some:
>> SATD:
>> ADD RD0, RQ0, RD13 //LI X13, 0
>> ADD RD0, RQ0, RD12 //LI X12, 0
>> MOV d, RQ16 //LA X16, d / ~ AUIPC+ADDI
>> MOV.L (RQ16, 0), RD10 //LW X10, 0(X16)
>> .L00800000:
>> MOV 16, RD11 //ADDI X11, X0, 16
>> BRGE.L RD11, RD12, .L00800002 //BGE X12, X11, .L00800002
SUBS.L R0, R10, R11 //SUBW X11, X0, X10
MAX R10, R11, R17 //-
>> ADDS.L RD13, RQ17, RD13 //ADDW X13, X17, X17
>> ADDS.L RD12, 1, RD12 //ADDIW X12, X12, 1
>> MOV.L (RQ16, RD12), RD10 //-
>> BSR .L00800000, R0 //J .L00800000
>> .L00800002:
>> ADDS.L RD13, RQ0, RD10 //ADDW X10, X13, X0
>> JSR R1, 0, R0 //RTS
More drastic reorg could save a few more instrs, but, ...
And, would be longer with plain RV64G as RV64G lacks indexed addressing, so:
MOV.L (RQ16, RD12), RD10
Would need to become, say:
SHLD.L R12, 2, R5
ADD R5, R16, R5
MOV.L (R5), RD10
Or, in RV ASM notation:
SLLW X5, X12, 2
ADD X5, X5, X16
LW X10, 0(X5)
Well, in case anyone needed a translation key...
> gcc-O2 does it in 13, but -O3 is longer due to using SIMD and no looping.
>
> However I then tried it in my systems language (an equivalent program)
> and there it was only 22 instruction, shown below. More amenable
> language features can help! Here also there is no out-of-bounds error.
>
> SATD:: # (uses non-standard reg names: A/D = 32/64 bits)
> R.satd = A3
> R.dd = A4
> R.k = A5
> push D3
> push D4
> push D5
> sub Dsp, 16
> ;---------------
> xor R.satd, R.satd
> xor A0, A0
> mov R.k, A0
> movsx D1, A0
> lea D0, [d]
> mov R.dd, [D0 + D1*4]
> jmp L4
> L5:
> cmp R.dd, 0
> jge L6
> mov A0, R.dd
> neg A0
> jmp L7
> L6:
> mov A0, R.dd
> L7:
> add R.satd, A0
> inc R.k
> mov A0, R.k
> movsx D1, A0
> lea D0, [d]
> mov R.dd, [D0 + D1*4]
> L4:
> cmp R.k, 16
> jl L5
> mov A0, R.satd
> L1:
> ;---------------
> add Dsp, 16
> pop D5
> pop D4
> pop D3
> ret
>
>
> ---------------------------
> Version in my language (uses 64-bit ints and is 1-based):
> ---------------------------
> [16]int d
>
> func satd:int =
> int sum:=0
>
> for x in d do # iterates over values
> sum +:= abs(x)
> end
>
> sum
> end
>
> ---------------------------
> t.satd:
> R.sum = D3
> R.av_1 = D4
> R.x = D5
> push R.sum
> push R.av_1
> push R.x
> sub Dsp, 16 # this is again not needed! (Same backend)
> ;---------------
> xor R.sum, R.sum
> mov D0, 1
> mov R.av_1, D0
> L2:
> mov R.x, [R.av_1*8 + t.d-8]
> mov D0, R.x
> cmp D0, 0
> jge L5
> neg D0
> L5:
> add R.sum, D0
> inc R.av_1
> cmp R.av_1, 16
> jle L2
> mov D0, R.sum
> L1:
> ;---------------
> add Dsp, 16
> pop R.x
> pop R.av_1
> pop R.sum
> ret
>
OK.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D’Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2026-07-25 22:32 +0000 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1143dhb$1rf0i$1@dont-email.me> |
| In reply to | #400401 |
On Sat, 25 Jul 2026 15:30:09 +0800, Johann 'Myrkraverk' Oskarsson wrote: > On 25/07/2026 3:24 PM, Lawrence D’Oliveiro wrote: >> >> On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson >> wrote: >> >>> The code is perfectly reasonable. >> >> If the code were “perfectly reasonable”, then there would be a >> compiler bug. There isn’t. > > That's a simple matter of debate. Back in the early days of computing, we had a principle called “GIGO” -- “Garbage In, Garbage Out”. That meant that, if you fed crap into the computer, don’t expect to get meaningful results out. Do they still teach that in “IT Studies”, or “Digital Technologies”, or whatever passes for CompSci courses these days?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-25 15:58 -0700 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1143f2q$1raai$2@kst.eternal-september.org> |
| In reply to | #400415 |
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Sat, 25 Jul 2026 15:30:09 +0800, Johann 'Myrkraverk' Oskarsson wrote:
>> On 25/07/2026 3:24 PM, Lawrence D’Oliveiro wrote:
>>> On Sat, 25 Jul 2026 15:20:21 +0800, Johann 'Myrkraverk' Oskarsson
>>> wrote:
>>>> The code is perfectly reasonable.
>>>
>>> If the code were “perfectly reasonable”, then there would be a
>>> compiler bug. There isn’t.
>>
>> That's a simple matter of debate.
>
> Back in the early days of computing, we had a principle called “GIGO”
> -- “Garbage In, Garbage Out”. That meant that, if you fed crap into
> the computer, don’t expect to get meaningful results out.
>
> Do they still teach that in “IT Studies”, or “Digital Technologies”,
> or whatever passes for CompSci courses these days?
The code has a fairly subtle bug (one that gcc 13.3.0 diagnoses with
"gcc -O1" or higher).
It seems clear that Johann simply missed the bug. Telling us that
If the code were “perfectly reasonable”, then there would be a
compiler bug. There isn’t.
is not helpful. Pointing out the actual bug (which others have
done by now) would have been helpful.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-07-25 10:23 +0200 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1141rpq$1bej1$1@dont-email.me> |
| In reply to | #400393 |
On 25/07/2026 00:08, bart wrote:
> On 24/07/2026 17:52, Johann 'Myrkraverk' Oskarsson wrote:
>> On 24/07/2026 8:47 PM, Janis Papanagnou wrote:
>>> On 2026-07-23 23:31, Keith Thompson wrote:
>>
>>>>
>>>> Certainly a warning would be nice. The problem is that unexpected
>>>> optimizations in the presence of undefined behavior don't always occur
>>>> because the compiler *knows* that the behavior is undefined.
>>>
>>> This thought or reasoning sounds completely perverted. - If the
>>> compiler *knows* that there's undefined behavior (that may lead
>>> to non-equivalent (=illegitimate) [dangerous] transformations!)
>>> a warning (or error message) should be *mandated* in any case!
>>> Without such a notice any "optimizations" (based on bizarre and
>>> hazardous assumptions) should never be performed! - Certainly a
>>> warning would not only be "nice" but should be mandated. - YMMV.
>>>
>>> It probably just boils down to the fact that the C-folks seem to
>>> imply another meaning of "optimization", meaning more something
>>> like "mutation of the code to something functionally different".
>>>
>>> Or, as it appear to me, that (with the knowledge of the inherent
>>> problems to overcome the issues) accommodated to the situation.
>>>
>>> Given what "C" actually is (and what it can *not* become) I don't
>>> think it makes sense to continue arguing about what I consider to
>>> be just the crazy facts of ("C"-)reality.
>>
>> Sounds like you want to read /What every compiler writer should know
>> about programmers/ by Anton Ertl, if you haven't already. Link at
>>
>> https://c9x.me/compile/bib/
>>
>
>
> This is an extract from that PDF:
>
> -------------------------------
> int d[16];
> int SATD (void) {
> int satd = 0, dd, k;
> for (dd=d[k=0]; k<16; dd=d[++k]) {
> satd += (dd < 0 ? -dd : dd);
> }
> return satd;
> }
>
> "This was “optimized” by a pre-release of gcc-4.8 into the following
> infinite loop:
>
> SATD:
> .L2:
> jmp .L2
>
> What happened? The compiler assumed that no out-of-bounds access to d
> would happen, and from that derived that k is at most 15 after the
> access, so the following test k<16 can be “optimized” to 1 (true),
> resulting in an endless loop. Then the compiler sees that the return is
> now unreachable, that satd is dead, that dd is dead, and k is dead, and
> optimizes the rest away."
>
> -------------------------------
>
> This is pretty crazy!
>
To me, the story of that example shows that the gcc folks have pretty
good development practices. The critical point, IMHO, is that this was
a /pre-release/ version of the compiler. They added some new stuff in
gcc 4.8, they tested with all their internal test suites and examples,
then they made a pre-release to encourage other people to test it and
see if there are any issues - either bugs in the compiler (this was not
a bug in gcc), or bugs in common existing code where people had relied
on particular behaviour despite the (presumably unnoticed) bugs in their
code.
That's what pre-release testing is for. It works for gcc. It found
this issue (a bug in the popular C benchmark code, no less). It finds
many other issues when pre-release gcc's are used for full re-builds of
big Linux distributions. Of course you won't find every bug in every
bit of C code when doing such pre-release testing, nor will you find
every bug in gcc itself. But it is helpful nonetheless.
gcc - the compiler and the development team - are the good guys in this
story.
And by gcc 4.9, the compiler was issuing warnings about the UB in the
source code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-24 16:29 -0700 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1140shk$11v1l$2@kst.eternal-september.org> |
| In reply to | #400391 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
[...]
> Sounds like you want to read /What every compiler writer should know
> about programmers/ by Anton Ertl, if you haven't already. Link at
>
> https://c9x.me/compile/bib/
>
> and more for everyone who wants to write his own C compiler.
I haven't read it yet, but I intend to (even though I'm not planning to
write my own C compiler).
> What some people have done, including me, is to simply lose faith in
> the C ISO committee, and started to write our own C compilers. This
> will make Mr. Singapore from the noise earlier very happy.
>
> Now, I decide how to react to this /Undefined behaviour/ means, and I
> disagree with the people behind the "big three" C compilers.
Do you mean that your own compiler will not conform to the C
standard, or merely that it will conform in different ways than the
"big three"?
If you think a compiler should not generate code based on the
assumption of defined behavior (for example, that it should generate
code for a statement even if that statement can be executed only if
undefined behavior has already occurred), that's fine, and nothing
in the C standard prevents it. There are plenty of things the C
standard permits compilers but does not require compilers to do.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-25 15:25 +0800 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <oxZ8S.240791$Xz_7.226057@fx06.ams4> |
| In reply to | #400395 |
On 25/07/2026 7:29 AM, Keith Thompson wrote: > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: > [...] >> Sounds like you want to read /What every compiler writer should know >> about programmers/ by Anton Ertl, if you haven't already. Link at >> >> https://c9x.me/compile/bib/ >> >> and more for everyone who wants to write his own C compiler. > > I haven't read it yet, but I intend to (even though I'm not planning to > write my own C compiler). > >> What some people have done, including me, is to simply lose faith in >> the C ISO committee, and started to write our own C compilers. This >> will make Mr. Singapore from the noise earlier very happy. >> >> Now, I decide how to react to this /Undefined behaviour/ means, and I >> disagree with the people behind the "big three" C compilers. > > Do you mean that your own compiler will not conform to the C > standard, or merely that it will conform in different ways than the > "big three"? I'm going to leave my disagreement with the "big three" as a surprise until release. > If you think a compiler should not generate code based on the > assumption of defined behavior (for example, that it should generate > code for a statement even if that statement can be executed only if > undefined behavior has already occurred), that's fine, and nothing > in the C standard prevents it. There are plenty of things the C > standard permits compilers but does not require compilers to do. > Indeed. If I remember correctly, loading the source code is /implementation defined/, so the compiler can perfectly well read NNTP instead of files, and strictly parse only code posted to comp.lang.c. I wonder if Mr. Singapore thought of that angle? -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-25 15:33 -0700 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1143dkd$1raai$1@kst.eternal-september.org> |
| In reply to | #400400 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
> On 25/07/2026 7:29 AM, Keith Thompson wrote:
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>> [...]
>>> Sounds like you want to read /What every compiler writer should know
>>> about programmers/ by Anton Ertl, if you haven't already. Link at
>>>
>>> https://c9x.me/compile/bib/
>>>
>>> and more for everyone who wants to write his own C compiler.
>> I haven't read it yet, but I intend to (even though I'm not planning
>> to
>> write my own C compiler).
>>
>>> What some people have done, including me, is to simply lose faith in
>>> the C ISO committee, and started to write our own C compilers. This
>>> will make Mr. Singapore from the noise earlier very happy.
>>>
>>> Now, I decide how to react to this /Undefined behaviour/ means, and I
>>> disagree with the people behind the "big three" C compilers.
>> Do you mean that your own compiler will not conform to the C
>> standard, or merely that it will conform in different ways than the
>> "big three"?
>
> I'm going to leave my disagreement with the "big three" as a surprise
> until release.
That's nice.
If you're not going to answer my question, why bother posting a followup
at all?
>> If you think a compiler should not generate code based on the
>> assumption of defined behavior (for example, that it should generate
>> code for a statement even if that statement can be executed only if
>> undefined behavior has already occurred), that's fine, and nothing
>> in the C standard prevents it. There are plenty of things the C
>> standard permits compilers but does not require compilers to do.
>
> Indeed. If I remember correctly, loading the source code is
> /implementation defined/, so the compiler can perfectly well
> read NNTP instead of files, and strictly parse only code posted
> to comp.lang.c.
That's completely irrelevant to what I wrote.
> I wonder if Mr. Singapore thought of that angle?
Who?
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> |
|---|---|
| Date | 2026-07-27 00:38 +0800 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <hKq9S.239270$OIh6.124089@fx13.ams4> |
| In reply to | #400416 |
On 26/07/2026 6:33 AM, Keith Thompson wrote: > Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >> On 25/07/2026 7:29 AM, Keith Thompson wrote: >>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes: >>> [...] >>>> Sounds like you want to read /What every compiler writer should know >>>> about programmers/ by Anton Ertl, if you haven't already. Link at >>>> >>>> https://c9x.me/compile/bib/ >>>> >>>> and more for everyone who wants to write his own C compiler. >>> I haven't read it yet, but I intend to (even though I'm not planning >>> to >>> write my own C compiler). >>> >>>> What some people have done, including me, is to simply lose faith in >>>> the C ISO committee, and started to write our own C compilers. This >>>> will make Mr. Singapore from the noise earlier very happy. >>>> >>>> Now, I decide how to react to this /Undefined behaviour/ means, and I >>>> disagree with the people behind the "big three" C compilers. >>> Do you mean that your own compiler will not conform to the C >>> standard, or merely that it will conform in different ways than the >>> "big three"? >> >> I'm going to leave my disagreement with the "big three" as a surprise >> until release. > > That's nice. > > If you're not going to answer my question, why bother posting a followup > at all? > >>> If you think a compiler should not generate code based on the >>> assumption of defined behavior (for example, that it should generate >>> code for a statement even if that statement can be executed only if >>> undefined behavior has already occurred), that's fine, and nothing >>> in the C standard prevents it. There are plenty of things the C >>> standard permits compilers but does not require compilers to do. >> >> Indeed. If I remember correctly, loading the source code is >> /implementation defined/, so the compiler can perfectly well >> read NNTP instead of files, and strictly parse only code posted >> to comp.lang.c. > > That's completely irrelevant to what I wrote. Right, you said something about defined, then undefined behaviour. I chose not to rise to the bait. If you word your question differently enough not to require either of those terms, I'll reply. Until then, happy C coding. > >> I wonder if Mr. Singapore thought of that angle? > > Who? > Message-ID: <113lv5q$3goh8$1@paganini.bofh.team> -- Johann | email: invalid -> com | http://www.myrkraverk.com/blog/ I'm not from the Internet, I just work there. | via Easynews.com
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-07-26 17:06 -0700 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <11467eu$2pbdl$1@kst.eternal-september.org> |
| In reply to | #400427 |
Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
> On 26/07/2026 6:33 AM, Keith Thompson wrote:
>> Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> writes:
>>> On 25/07/2026 7:29 AM, Keith Thompson wrote:
[...]
>>>> If you think a compiler should not generate code based on the
>>>> assumption of defined behavior (for example, that it should generate
>>>> code for a statement even if that statement can be executed only if
>>>> undefined behavior has already occurred), that's fine, and nothing
>>>> in the C standard prevents it. There are plenty of things the C
>>>> standard permits compilers but does not require compilers to do.
>>>
>>> Indeed. If I remember correctly, loading the source code is
>>> /implementation defined/, so the compiler can perfectly well
>>> read NNTP instead of files, and strictly parse only code posted
>>> to comp.lang.c.
>>
>> That's completely irrelevant to what I wrote.
>
> Right, you said something about defined, then undefined behaviour. I
> chose not to rise to the bait. If you word your question differently
> enough not to require either of those terms, I'll reply. Until then,
> happy C coding.
There was no bait. I asked you a question about how you intend
your proposed compiler to deal with undefined behavior. You are of
course not required to answer, but your choice to post a reply about
something else was odd. I won't be wording my question differently;
what you're suggesting is that I ask an entirely different
question.
I suspect that attempting to communicate with you will not be
productive. I would enjoy having my suspicion refuted.
>>> I wonder if Mr. Singapore thought of that angle?
>> Who?
>>
> Message-ID: <113lv5q$3goh8$1@paganini.bofh.team>
So there's a user posting under the name "Singapore" who has posted
here exactly once, saying nothing relevant or interesting. I have
no idea why you'd feel the need to mention him or her (and no,
I'm not asking).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Cóilín Nioclásín Glostéir <thanks-to@Taf.com> |
|---|---|
| Date | 2026-07-26 17:03 +0000 |
| Subject | Re: Resources for Amateur Compiler Writers |
| Message-ID | <1145eki$1etq9$1@paganini.bofh.team> |
| In reply to | #400391 |
More resources for creating a compiler - news:comp.compilers (S. HTTP://Gloucester.Insomnia247.NL/ fuer Kontaktdaten!)
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web