Re: C compiler (over-)optimization (was: netbsd-11 gcc bug)

"Greg A. Woods" <[email protected]> Fri, 29 May 2026 14:27:39 -0700
Newsgroups gmane.os.netbsd.devel.toolchain
Organization Planix, Inc.
Message-ID <[email protected]>
--pgp-sign-Multipart_Fri_May_29_14:27:23_2026-1
Content-Type: text/plain; charset=US-ASCII

At Fri, 29 May 2026 14:21:18 -0400 (EDT), Mouse <[email protected]> wrote:
Subject: Re: C compiler (over-)optimization (was: netbsd-11 gcc bug)
>
> I think you/we just need two flavours of C compilers: ones for
> applications and ones for OS implementations (or possibly three, with
> the third one being for benchmarks).  Formally-undefined behaviour is
> not a problem, after all, if you can count on having a compiler that
> turns it into what you actually want.  A compiler can define, document,
> and support semantics for something that is formally UB, after all;
> that is entirely within the leeway the spec permits.
>
> What you really need is a compiler supplier that understands that
> usefulness is the true metric of goodness, as opposed to benchmarks or
> even strict spec conformance, that "but it conforms to the spec" is not
> an appropriate response to a bug report such as might have come out of
> the example that started this discussion.  Well, understands that and
> considers the use cases you care about important enough to supply a
> compiler for.

The problem in the narrower context of open-source operating systems is
that we have basically two compiler "vendors" that egg each other on and
play "keep up with the Jones's" between each other, and that includes
"abusing" UB to make optimisations and do other "unexpected" things that
basically break legacy code.  I guess it could be worse and there be
only one.

So what you're basically asking for is more or less what Edgar proposed:
A new systems programming language (that is effectively a variant of
"Standard C") -- and one that forbids being initially implemented as a
front-end for either GCC or LLVM where too much happens under the hood
(i.e. in the backend, including LTO).

Maybe we go back to PCC and make sure it evolves to conform to a variant
of C where there is no UB -- only IDB, i.e. as you said, the compiler
explicitly defines semantics for everything that the C Lawyers call UB.

And then maybe if that works well enough and is popular enough it could
be extended as a semi-formal new variant of C that the other compiler
vendors could implement.  Then instead of a whole slew/slough of
"-fno-break-this-construct" flags for those other vendor compiler turn
into just one:  "-std=NewC" (or maybe we call it "L", as I propose in my
notes on C).

--
					Greg A. Woods <[email protected]>

Kelowna, BC     +1 250 762-7675           RoboHack <[email protected]>
Planix, Inc. <[email protected]>     Avoncote Farms <[email protected]>

--pgp-sign-Multipart_Fri_May_29_14:27:23_2026-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit
Content-Description: OpenPGP Digital Signature

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCahoEvgAKCRBmfXG3eL/0
f+R9AJ9dsJ8koDDXNbwmp4Pl1neOOha2RwCfZP56/k60A9QCeDAqYJKU61YAJmE=
=4/8o
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Fri_May_29_14:27:23_2026-1--