gcc optimizations cause app to fail

Question

I'm having a real strange problem using GCC for ARM with the optimizations turned on. Compiling my C++ application without the optimizations produces an executable that at runtime outputs the expected results. As soon as I turn on the optimizations - that is -O1 - my application fails to produce the expected results. I tried for a couple of days to spot the problem but I'm clueless. I eliminated any uninitialized variables from my code, I corrected the spots where strict aliasing could cause problems but still I do not have the proper results.

I'm using GCC 4.2.0 for ARM(the processor is an ARM926ej-s) and running the app on a Montavista Linux distribution.

Below are the flags I'm using:

-O1 -fno-unroll-loops fno-merge-constants -fno-omit-frame-pointer -fno-toplevel-reorder \
-fno-defer-pop -fno-function-cse -Wuninitialized -Wstrict-aliasing=3 -Wstrict-overflow=3 \
-fsigned-char -march=armv5te -mtune=arm926ej-s -ffast-math

As soon as I strip the -O1 flag and recompile/relink the application I get the proper output results. As you can see from the flags I tried to disable any optimization I thought it might cause problems but still no luck.

Does anyone have any pointers on how I could further tackle this problem?

Thanks

Answer 1

Generally speaking, if you say "optimization breaks my program", it is 99.9% your programm that is broken. Enabling optimizations only uncovers the faults in your code.

You should also go easy on the optimization options. Only in very specific circumstances will you need anything else beyond the standard options -O0, -O2, -O3 and perhaps -Os. If you feel you do need more specific settings than that, heed the mantra of optimizations:

Measure, optimize, measure.

Never go by "gut feeling" here. Prove that a certain non-standard optimization option does significantly benefit your application, and understand why (i.e., understand exactly what that option does, and why it affects your code).

This is not a good place to navigate blindfolded.

And seeing how you use the most defensive option (-O1), then disable half a dozen optimizations, and then add -ffast-math, leads me to assume you're currently doing just that.

Well, perhaps one-eyed.

But the bottom line is: If enabling optimization breaks your code, it's most likely your code's fault.

EDIT: I just found this in the GCC manual:

-ffast-math: This option should never be turned on by any -O option since it can result in incorrect output for programs which depend on an exact implementation of IEEE or ISO rules/specifications for math functions.

This does say, basically, that your -O1 -ffast-math could indeed break correct code. However, even if taking away -ffast-math removes your current problem, you should at least have an idea why. Otherwise you might merely exchange your problem now with a problem at a more inconvenient moment later (like, when your product breaks at your client's location). Is it really -ffast-math that was the problem, or do you have broken math code that is uncovered by -ffast-math?

Answer 2

-ffast-math should be avoided if possible. Just use -O1 for now and drop all the other optimisation switches. If you still see problems then it's time to start debugging.

Answer 3

Without seeing your code, it's hard to get more specific than "you probably have a bug".

There are two scenarios where enabling optimizations changes the semantics of the program:

• there is a bug in the compiler, or
• there is a bug in your code.

The latter is probably the most likely. Specifically, you probably rely on Undefined Behavior somewhere in your program. You rely on something that just so happen to be true when you compile using this compiler on this computer with these compiler flags, but which isn't guaranteed by the language. And so, when you enable optimizations, GCC is under no obligation to preserve that behavior.

Show us your code. Or step through it in the debugger until you get to the point where things go wrong.

I can't be any more specific. It might be a dangling pointer, uninitialized variables, breaking the aliasing rules, or even just doing one of the many things that yield undefined results (like i = i++)

Answer 4

Try to make a minimal test case. Rewrite the program, removing things that don't affect the error. It's likely that you'll discover the bug yourself in the process, but if you don't, you should have a one-screen example program you can post.

Incidentally, if, as others have speculated, it is -ffast-math which causes your trouble (i.e. compiling with just -O1 works fine), then it is likely you have some math in there you should rewrite anyhow. It's a bit of an over-simplification, but -ffast-math permits the compiler to essentially rearrange computations as you could abstract mathematical numbers - even though doing so on real hardware may cause slightly different results since floating point numbers aren't exact. Relying on that kind of floating point detail is likely to be unintentional.

If you want to understand the bug, a minimal test-case is critical in any case.