Hacker News Reader

Comment by arximboldi | Hacker News Reader

Actually the optimization is not statically initializing Do, it is inlining the function calls via the Do pointer. I actually think this a quite useful optimization.

You can see that if you "fix" the program by checking Do before calling it, it still inlines the call in the True branch:

https://godbolt.org/g/9KS2r9

View on HN

Of course, in some cases NULL checks will be optimized out (this is why GCC has acquired the -fno-delete-null-pointer-checks flag ...). At one point, this has been a huge source of conflict: basically, when you have something like

if (NULL != s) { s->a = 1; }

s->b = 1;

then GCC may optimize away the NULL check because referring to s->b after the block protected by the NULL check indicates that the NULL check is superfluous. I this case, this is actually true, but in cases that involve aliasing that is not detected by dataflow analysis, there might be circumstances where the NULL check is required. Discussion of something related is here[0]; my example might not be very good.

An even more insidious case is [1](strong language), where manual overflow checks are optimized out because the overflow technically invokes UB.

Compiler optimization gone wild.

[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71892 [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30475

Your example also presents undefined behaviour, so the compiler is free to do whatever it wants.

That's like saying "You used the power drill incorrectly, so it's free to explode and burn your house down."

At some point safety matters, and the more likely human mistakes matter.

Reply on news.ycombinator.com