Hacker News Reader

Comment by JdeBP | Hacker News Reader

The bug report is better reading: https://bugs.llvm.org/show_bug.cgi?id=49599

The issue seems to miss the heart of the problem. We know GCC and Clang have both intended for some time to treat undefined behavior as an opportunity to do whatever they want. If we assume the loop doesn't halt, we can remove the RET instruction. If we assume it does halt then we can remove the loop. Clang's internal model at HEAD appears to be assuming both outcomes happen simultaneously, which is clearly a bug, but could also indicate some kind of deeper policy change surrounding the liberties which are taken with behaviors that are undefined according to the C standard.

The behavior is hostile and dangerous, but legal.

If undefined behavior would happen during an execution of a program, then that entire execution of the program is undefined behavior from the start.

Since all possible executions of this program will lead to undefined behavior, the compiler was free to emit any other program. It is permitted to get rid of all the code. You could say that Clang 13 missed an optimization opportunity here. It could have produced an empty file.

Obligatory Meme: https://justine.lol/undefined.png

> Clang's internal model at HEAD appears to be assuming both outcomes happen simultaneously, which is clearly a bug

How is it clearly a bug? Undefined means undefined.

Undefined doesn't mean contradiction in the sense that anything becomes possible. It just means it can be defined however you want, and if you choose an unsound definition then that reflects on you. Think about the history of how X3J11 was able to get people like UNIVAC and EDVAC to agree on the C standard even though they had wildly different ideas on how things like how the sign bit should work. The only way to forge a compromise is to simply say, OK, the standard won't broach that topic, keep doing what you're doing.

> in the sense that anything becomes possible

In C and C++, that's exactly what undefined behavior means. I think you're confusing it with unspecified behavior.

Because in practice, compilers are expected to do more than the language standard requires of them, and this resulting behavior is very dangerous.

The trouble dates back to the original standardization of C. An expectation of pre-standard C was left out of the standard: behavior of things like integer overflow could be determined by looking at the CPU documentation. It would have been difficult to turn that into an unambiguous requirement in the standard, and it is unlikely that people imagined what future compilers might do.

In the decades since, benchmark competition has given us the hostile mess we have today.

Reply on news.ycombinator.com