Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > muc.lists.netbsd.tech.toolchain > #3615

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

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

At Fri, 29 May 2026 14:21:18 -0400 (EDT), Mouse <mouse@Rodents-Montreal.ORG> 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 <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

Back to muc.lists.netbsd.tech.toolchain | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 10:59 +0200
  Re: netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 12:55 +0200
    Re: netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 20:45 +0200
  Re: netbsd-11 gcc bug Valery Ushakov <uwe@stderr.spb.ru> - 2026-05-23 14:22 +0300
    Re: netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 13:28 +0200
  Re: netbsd-11 gcc bug Roland Illig <roland.illig@gmx.de> - 2026-05-23 20:38 +0200
    Re: netbsd-11 gcc bug Manuel Bouyer <bouyer@antioche.eu.org> - 2026-05-23 20:47 +0200
      Re: netbsd-11 gcc bug Robert Elz <kre@munnari.OZ.AU> - 2026-05-24 02:29 +0700
        Re: netbsd-11 gcc bug Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-23 19:11 -0400
          Re: netbsd-11 gcc bug Martin Husemann <martin@duskware.de> - 2026-05-24 10:44 +0200
            Re: netbsd-11 gcc bug Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-24 08:33 -0400
              Re: netbsd-11 gcc bug Jason Thorpe <thorpej@me.com> - 2026-05-24 11:38 -0400
                Re: netbsd-11 gcc bug "Greg A. Woods" <woods@planix.ca> - 2026-05-24 16:53 -0700
              Re: netbsd-11 gcc bug David Holland <dholland-tech@netbsd.org> - 2026-05-25 00:02 +0000
                Re: netbsd-11 gcc bug Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-25 08:23 -0400
                C compiler (over-)optimization (was: netbsd-11 gcc bug) Edgar Fuß <ef@math.uni-bonn.de> - 2026-05-29 19:12 +0200
                Re: C compiler (over-)optimization (was: netbsd-11 gcc bug) Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-29 14:21 -0400
                Re: C compiler (over-)optimization (was: netbsd-11 gcc bug) "Greg A. Woods" <woods@planix.ca> - 2026-05-29 14:27 -0700
                Re: C compiler (over-)optimization Anders Magnusson <ragge@tethuvudet.se> - 2026-05-30 12:30 +0200
                Re: C compiler (over-)optimization (was: netbsd-11 gcc bug) Andrew Cagney <andrew.cagney@gmail.com> - 2026-05-31 13:02 -0400
                Re: C compiler (over-)optimization (was: netbsd-11 gcc bug) Jason Thorpe <thorpej@me.com> - 2026-05-31 14:29 -0500
                Re: netbsd-11 gcc bug "Greg A. Woods" <woods@planix.ca> - 2026-05-28 14:40 -0700
                Re: netbsd-11 gcc bug Mouse <mouse@Rodents-Montreal.ORG> - 2026-05-28 18:36 -0400
                Re: netbsd-11 gcc bug Jason Thorpe <thorpej@me.com> - 2026-05-28 19:04 -0400
                Re: netbsd-11 gcc bug "Greg A. Woods" <woods@planix.ca> - 2026-05-29 14:31 -0700
      Re: netbsd-11 gcc bug Jörg Sonnenberger <joerg@bec.de> - 2026-05-26 13:52 +0200
        Re: netbsd-11 gcc bug Jason Thorpe <thorpej@me.com> - 2026-05-26 10:02 -0400

csiph-web