CODEWITHSUNDEEP
c++gccoptimization
TrezzJo
TrezzJo

Reputation: 120

g++ enables wrong flags at -Os

at the moment I am doing some experiments with the GNU C++-Compiler and the -Os optimization option for minimal code size. I checked the enabled compiler flags at -Os with the following command: 

g++ -c -Q -Os --help=optimizers | grep "enabled"


I got this list of enabled options:

-faggressive-loop-optimizations [enabled]
-falign-functions               [enabled]
-falign-jumps                   [enabled]
-falign-labels                  [enabled]
-falign-loops                   [enabled]
-fasynchronous-unwind-tables    [enabled]
                 ...


This seems a bit strange, because I also looked up, which flags should be enabled at -Os, here and under the -Os section it is written that all the falign- options should be disabled for code minimization.


Q: So is this a bug or am I doing something wrong here ? Cause after reading what the falign- flags do I really think they should be disabled in -Os !



My gcc-version is 4.9.2 and I am working on Arch-Linux.

Already thanks for helping :)

Upvotes: 6

Views: 122

Answers (1)

jww
jww

Reputation: 102346

Q: So is this a bug or am I doing something wrong here ? Cause after reading what the falign- flags do I really think they should be disabled in -Os

I think Hans did a good job of finding part of the problem. Its definitely a documentation bug. But no one from GCC commented on why -Os enabled them, so you might not have all of the information.

Older ARM devices were very intolerant of unaligned accesses. Older arm devices included ARMv4 and I think ARMv5. If you performed an unaligned access, you would get a SIGBUS (been there, done that, got the tee shirt).

Modern ARM devices fix up unaligned accesses like x86 processors do, so you no longer get a SIGBUS. Instead, you just take the performance penalty.

You should try to specify an architecture in case those options are an artifact from older ARM device support. For example, -march=armv7. If you find it on ARMv6 and ARMv7, then that could still be a bug. It depends if the GCC team decided the tradeoff was sufficient for ARM (code size vs performance penalty).

Upvotes: 2

Related Questions