Hacker News Reader

Comment by nikanj | Hacker News Reader

I wish there was a GCC switch that made the optimizer go "This is clearly undefined behaviour. I'll stop this compile right here", as opposed to "This is clearly undefined behaviour. Sweet jackpot, it means I can do whatever the heck I want. Drop those NULL checks below, I've got the golden UDB ticket now"

View on HN

The optimizer doesn't work that way. It assumes the code does not do UB and then removes branches that can never be taken if the code executes no UB.

That's different from "This is UB, and now I do ...".

I think we deserve a compiler warning whenever a source line of code (not a line generated by the preprocessor) gets removed due to UB exploitation. All such cases are worth the programmer's attention, because they are either useless lines or bugs.

It's more complicated than this, unfortunately. Imagine an int variable x and two expressions f(x) and g(x) of x. Now imagine an if statement with condition f(x) < g(x). Precisely because incrementing the largest int is undefined behavior, the compiler may be able to simplify the if condition because, for example, it can assume x+1 > x is always true. So it's not necessary for the line to be useless or wrong for undefined behavior rules to trigger compiler optimizations.

You must also account for the case where the source line removed was only useless because of the specific context it had been inlined to by an earlier stage of the optimiser.

It's not as easy as it seems.

In C `x + 1` is an undefined behavior if `x` is signed and overflows. Optimizer takes advantage of that for loop optimizations.

Reply on news.ycombinator.com