Optimization flags cause incorrect computation

Question

I am having a weird optimisation-only bug so I am trying to determine which flag is causing it. The error (incorrect computation) occurs with -O1 , but not with -O0 . Therefore, I thought I could use all of the -f flags that -O1 includes to narrow down the culprit . However, when I try that (using this list http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html ), it works fine again!

Can anyone explain this, or give other suggestions of what to look for? I've run the code through valgrind , and it does not report any errors.

EDIT

I found that the computation is correct with -O0 , incorrect with -O1 , but correct again with -O1 -ffloat-store . Any thoughts of what to look for that would cause it not to work without -ffloat-store ?

EDIT2

If I compile with my normal release flags, there is a computation error. However, if I add either:

-ffloat-store

or

-mpc64

to the list of flags, the error goes away.

Can anyone suggest a way to track down the line at which this flag is making a difference so I could potentially change it instead of requiring everyone using the code to compile with an additional flag?

Answer 1

From back in my GCC/C++ days the optimization bug like this that I remember was that with -O0 on methods where no return value was specified would return the last value of that type in the method (probably what you wanted to return right?) whereas with optimisations on it returned the default value for the type, not the last value of the type in the method (this might only be true for value types, I can't remember). This would mean you would develop for ages with the debug flags on and everything would look fine, then it would stop working when you optimised.

For me not specifying a return value is a compilation error, but that was C++ back then.

The solution to this was to switch on the strongest set of warnings and then to treat all warnings as errors: that will highlight things like this. (If you are not already doing this then you are in for a whole load of pain!)

If you already have all of the errors / warnings on then the only other option is that a method call with side-effects is being optimised out. That is going to be harder to track down.