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?