How GCC and Clang handle statically known undefined behaviour

Im a member of the wg14 and the Undefined beahviour study group. We are producinga technical rapport about UB and one thing we specificly point out is that staticly known UB should be treated as an error, not as "this cant be called" aka "unreachable". From what i have seen LLVM sometimes issues poison when it should just issue an error. The implications can be quite severe. Instead of assuming that a UB is programmer error, it assumes its the intention of the programer that the code will never run, therfor it can use this information to make assumptions about branching behaviour.

> Somewhat expectedly, gcc remains faithful to its crash approach, though note that it only inserts the crash when it compiles the division-by-zero, not earlier, like at the beginning of the function. […] The mere existence of UB in the program means all bets are off and the compiler could chose to crash the function immediatley upon entering it.

GCC leaves the print there because it must. While undefined behaviour famously can time travel, that’s only if it would actually have occurred in the first place. If the print blocks indefinitely then that division will never execute, and GCC must compile a binary that behaves correctly in that case.

Needs the "how" in the title restored; see https://news.ycombinator.com/item?id=40728590.

> While the compiled programs stayed the same, we no longer get a warning (even with -Wall), even though both compilers can easily work out statically (e.g. via constant folding) that a division by zero occurs [4].

Are there any reasons why that is so? Do compilers not reuse the information they gather during compilation for diagnostics? Or is it a deliberate decision?

The way the compilers abuse undefined behavior to "optimize" away sanity checks we explicitly put in is just downright insane to me

> clang used the fact that division by zero is undefined and thus argc must not be zero to entirely remove the condition if (argc == 0), knowing this case can never happen [2].

Serious logic error, surely. "Can never happen" does not follow.

> language specification doesn't define what should happen during execution.

this is subtile misleading unspecified and undefined behavior are not quite the same

UB means it's (simplified) specified that the compiler is allowed to do whatever it wants (or more concretely in most cases is allowed to assume that a specific thing is impossible when optimizing to a point where of it does happen pretty much anything can happen including things like it seeming that an int is two different values at the same time or (which might still be one of the more harmless wtfs which can happen))

Note that this article is incorrect about "The mere existence of UB in the program means all bets are off and the compiler could chose to crash the function immediatley upon entering it.". In C this is not true.

  int i = 0;
  // nullptr dereference
  int ub = *(int*)i;

It is implementation defined I think, not UB. 0 could be a valid address

This post has no point.

Developers must avoid UB in their code, at all costs. Wondering what a specific compiler will do with your UB code is useless: as soon as you realise you have UB, go and fix it!

To me, the very fact that one of the most used Programming languages ever, has undefined behavior - boggles the mind. IMO It is one of the worst parts of C (other than using pointers for Arrays, its string implementation and 0 based indices).

I really don't understand why the C standards body can't just define what should be the intended failure behavior in case of specific UB cases, and then the compiler developers to onboard this spec. There should be no impact to backwards compat because

a. this will be a new C version b. No program ever should be defined around the UB behavior

But UB still exist in 2024 and will likely do till I am too old to whine on the internet about it.