to be fair most of that is GCC/C's fault. C has tons of UB that is very difficult to reason about, and GCC chooses to do weird things by default that are at best ambiguously standard compliant (e.g. evaluating floating point expressions in higher than specified by the user). Compilers of languages with more intuitive semantics tend to get less user error bug reports.

> that are at best ambiguously standard compliant (e.g. evaluating floating point expressions in higher than specified by the user).

That's not ambiguously standards-compliant, that is literally something that the standard has explicit mechanisms to indicate that's what the compiler is doing (look up FLT_EVAL_METHOD).

the way GCC does it doesn't quote follow the meaning of any of the options of FLY_EVAL_METHOD at least as I read it. it's close to 2 (i.e. all operations and constants evaluate in the range and precision of long double), but it's actual semantics are that some random subset of it's math is done in 80 bit (which isn't the size of is long double), except when that doesn't happen and it used 64 bit instead. that said, I guess you could call this standard compliant, since the standard says that negative options other than -1 are implementation defined behavior, so maybe the GCC default is to set the option to one of the values allowed by, but not documented in, the standard. https://stackoverflow.com/a/20870215/5141328 documents the insanity pretty well

it may be helpful to have the context that gumby's years on gcc were something like 01987–01997, before most of the ub fuckery

Honestly, mostly they were vanilla misunderstanding of the language being compiled.

Some people would rather blame the compiler than their own code.

Others were shocked that a compiler could have a bug at all. Because most code is not corner cases, this isn’t a bad default assumption, really, but bugs do happen.