It seems this example of the paper is correct in the sense that this really did occur. Following the link I found this bug report. The example code is:syzygy wrote:I agree, even if a function is not guaranteed to not return, in a specific case it might not return and the undefined behavior would/should never be triggered.lucasart wrote:The exampole you show is -- I believe -- an abusive optimiation by the compiler (IOW a true GCC bug). AFAIK there is nothing in the standard that allows the compiler to perform that optimization. The "as if" of the standard does not apply here, unless the compiler can prove that the ereport() function cannot change the control flow. Obviously, if there is an exit() statement somewhere in the *possible* call tree of ereport(), as well as a longjmp() or a throw in C++ for example, the compiler cannot make such an assumption.
More generally, I don't think "provably" undefined behavior later in the program should allow a compiler to optimise the whole program away. The computer should do exactly what the programmer told it to do (in particular cause all the externally visible side effects), up to the point that it actually runs into the undefined behavior. In other words, undefined behavior may cause demons to fly out of your nose, but it may not result in time travel.
You probably mean clang bug, if clang in fact does what the author suggests it does.Perhaps using flto fixes the problem, as the code is generated at link time from the bytecode produced at compile time (so the code of ereport() is visible, rather than just an extern declaration). I think this one is a true GCC bug.
But maybe I should read the paper again to be sure that I understand the author's point and that I am not reading too much into it.
edit: oops, this was indeed about gcc. More reason to study the paper a bit better.
Code: Select all
#include <stdio.h>
int testdiv(int i, int k) {
if (k == 0) printf("found divide by zero\n");
return(i/k);
}
int main() {
int i = testdiv(1,0);
return(i);
}
Two people pointed out that the program is invoking undefined behavior and the bug got status "RESOLVED INVALID".
I think it is very clear that this is in fact a compiler bug. That certain code has undefined behavior does NOT mean it is unreachable. I do not believe that anything in the C standard allows statements with undefined behavior to be treated as unreachable.
The C standard defines the semantics of a C program. Certain aspects it leaves undefined, e.g. the result of a division by zero is undefined. That means that once a division by zero is encountered, anything can happen. It does not mean that once a division by zero is encountered, the program can travel back in time and undo the side effect of the printf() that was executed fully in conformance with defined behavior.
So this is/was simply a gcc bug.