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

Groups > muc.lists.netbsd.tech.toolchain > #3593 > unrolled thread

netbsd-11 gcc bug

Back to article view | Back to muc.lists.netbsd.tech.toolchain

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

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

Sorry for the top post, and please excuse any thumb-o’s.

100% agree that compiler lock-in is bad and that we should strive to be as compiler-agnostic as possible.  (I have other thoughts on the compiler topic, but I’m in an airport bar typing on my phone, so that will have to wait.)

With GCC, it certainly used to be that -ffreestanding was sufficient to disable some of the egregious stuff that gave the kernel ulcers, but I’m not sure that’s the case anymore, and in my own silly not-really-hosted-C endeavors, I have decided that’s a battle I’m no longer willing to fight.

-- thorpej
Sent from my iPhone.

> On May 31, 2026, at 12:02 PM, Andrew Cagney <andrew.cagney@gmail.com> wrote:
> 
> 
>> 
>> 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.
> 
> That runs the risk of compiler and language lock-in.
> 
> I'm more worried about things like this:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125524

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

[toc] | [prev] | [next] | [standalone]

#3610

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

This probably/obviously isn't the best place for this discussion, but...

At Mon, 25 May 2026 00:02:17 +0000, David Holland <dholland-tech@netbsd.org> wrote:
Subject: Re: netbsd-11 gcc bug
>
> The places where
> certain bits of undefined and unspecified behavior line up exactly
> with things that mattered in a compiler written forty years ago are no
> longer obvious, and so what's left is a vague general belief that the
> UB in the C standard is meant to be room for optimizers.

The reason for the "belief" that UB is (often) related to optimizers is
squarely resting on the fact that when the optimizer is turned off then
the UB goes away.  So it's not really a belief -- it's a demonstrable
fact!

That and the fact some of the compiler maintainers influencing the
standard have basically said that they explicitly rely on some UB
conditions to allow their optimization tricks to work.

So it's very difficult to separate many of the current cases of UB from
some aspect of optimization.

> You can try pushing back, but you aren't going to get anywhere.

As I said, efforts to eliminate UB from C are actually happening at the
standards committee level, so....

--
					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>

[toc] | [prev] | [next] | [standalone]

#3611

> The reason for the "belief" that UB is (often) related to optimizers
> is squarely resting on the fact that when the optimizer is turned off
> then the UB goes away.

No, it doesn't.  It is still UB.  All that changes is what the compiler
chooses to do in that case where its behaviour is undefined by the
spec.

A more accurate phrasing would be that the compiler's choice of
behaviour changes depending on optimization.

The compiler must do *something* when faced with UB, whether it's
compiling code that does what the source author intended, segfaulting,
making usefulness-impairing inferences, or (in non-runtime cases)
printing all primes from 2 to 4294967291 at compile time.  UB just
means that the spec does not constrain what the compiler does.

> As I said, efforts to eliminate UB from C are actually happening at
> the standards committee level, so....

That will be difficult, unless some of them are handled by converting
UB to IDB by fiat.  Indirecting through a garbage pointer comes to mind
as an example.  (You're not going to get rid of garbage pointers
without crippling the language for use cases such as implementing VM
subsystems.)

/~\ 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

[toc] | [prev] | [next] | [standalone]

#3612

> On May 28, 2026, at 5:40 PM, Greg A. Woods <woods@planix.ca> wrote:
> 
> The reason for the "belief" that UB is (often) related to optimizers is
> squarely resting on the fact that when the optimizer is turned off then
> the UB goes away.  So it's not really a belief -- it's a demonstrable
> fact!

Eh.. The undefined behavior doesn’t go away, per se, it just is undefined differently :-)

Maybe a better say to state it is: “when the optimizer is turned off, the unexpected behavior goes away”.

-- thorpej


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

[toc] | [prev] | [next] | [standalone]

#3616

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

At Thu, 28 May 2026 19:04:07 -0400, Jason Thorpe <thorpej@me.com> wrote:
Subject: Re: netbsd-11 gcc bug
> 
> 
> > On May 28, 2026, at 5:40 PM, Greg A. Woods <woods@planix.ca>
> > wrote:
> >  The reason for the "belief" that UB is (often) related to
> > optimizers is squarely resting on the fact that when the
> > optimizer is turned off then the UB goes away.  So it's not
> > really a belief -- it's a demonstrable fact!
> 
> Eh.. The undefined behavior doesn t go away, per se, it just is
> undefined differently :-)
> 
> Maybe a better say to state it is:  when the optimizer is turned
> off, the unexpected behavior goes away .

Yes, indeed that's much more like what I meant!  A different expansion
of the abbreviation "UB"!

-- 
					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>

[toc] | [prev] | [next] | [standalone]

#3608

On 5/23/26 8:47 PM, Manuel Bouyer wrote:
> I guess there's still variants of offsetof() around which uses this.

offsetof() follows somewhat different rules as it is explicitly an 
unevaluated context.

Joerg

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

[toc] | [prev] | [next] | [standalone]

#3609

> On May 26, 2026, at 7:52 AM, Jörg Sonnenberger <joerg@bec.de> wrote:
> 
> On 5/23/26 8:47 PM, Manuel Bouyer wrote:
>> I guess there's still variants of offsetof() around which uses this.
> 
> offsetof() follows somewhat different rules as it is explicitly an unevaluated context.

Sure, but some compilers also get upset with the classical definition of offsetof(), and the only way to really fix it is to use the compiler intrinsic.

-- thorpej


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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | muc.lists.netbsd.tech.toolchain

csiph-web