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

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

Re: netbsd-11 gcc bug

Show all headers | View raw

>> I'd say this should be filed as a bug with the gcc people; if they
>> can't/won't fix it, NetBSD should roll back to a previous gcc and/or
>> drop gcc as the system compiler, as then it'd be clearly unsuitable.

(I perhaps should have added "as the self-hosting compiler for
NetBSD".)

> It is not about gcc or clang, it is about the C standard, which is
> created by an open comittee and you are welcome to send defect
> reports and/or ask for clarifictaions.

Which is fair - but compilers do not have to take advantage of all the
leeway the standard gives them.  "Undefined behaviour" can, after all,
include "exactly what the code author intended".

> The compiler using all strength the standard gives it is just a
> logical consequence of the user asking it to optimize.

Then, for the sake of being useful, it needs a setting that is "do most
optimizations, but don't make such unreasonable inferences about
formally-undefined behaviour".

Perhaps the gcc people are able-and-willing to do that.  But, if not, I
still maintain that it is thereby unsuitable for the use case of
building NetBSD.

The standard is an attempt to satisfy everyone; the result is a
compromise, and gives too much leeway for some use cases and not enough
for others - repeated, of course, for each point on which there is
potential leeway.  If &p->member is undefined behaviour when p is nil,
the correct thing for a *useful* compiler to do is not to simply assume
p is non-nil, at least not unless specifically told to; it is to test
for nil and take some suitable action - indirect through it, call a
(possibly invocation-dependent) routine, *something* better than
silently propagating the inference.  Especially in the presence of an
explicit test for nil later!

> But fixing the code to avoid "undefined behaviour" is the proper
> solution and fits NetBSD's clean code mission well.

Well, none of this is my call to make.  But I still think it excessive
for the compiler to cause formally-undefined behaviour to elide
explicit tests, especially when told to run freestanding.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse@rodents-montreal.org
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

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