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

Sorry for the top post, and please excuse any thumb-o=E2=80=99s.

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

With GCC, it certainly used to be that -ffreestanding was sufficient to disa=
ble some of the egregious stuff that gave the kernel ulcers, but I=E2=80=99m=
 not sure that=E2=80=99s the case anymore, and in my own silly not-really-ho=
sted-C endeavors, I have decided that=E2=80=99s a battle I=E2=80=99m no long=
er willing to fight.

-- thorpej
Sent from my iPhone.

> On May 31, 2026, at 12:02=E2=80=AFPM, Andrew Cagney <[email protected]=
om> wrote:
>=20
> =EF=BB=BF
>>=20
>> 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.
>=20
> That runs the risk of compiler and language lock-in.
>=20
> I'm more worried about things like this:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D125524