https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63625
Bug ID: 63625
Summary: -flto breaks optimization during link phase on
arm-none-eabi without -O on linker (!) command line
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anpaza at mail dot ru
Created attachment 33790
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33790&action=edit
A test source file & build shell script demonstrating the bug
I use arm-none-eabi-gcc (Fedora 2013.11.24-2.fc19) 4.8.1.
When compiling and linking "as usual" with the -flto switch the resulting
executable is not optimized.
It looks like the code gets recompiled again somehow if -flto was specified on
linker command line (I'm not sure how exactly -flto works but I suppose it
relinks the whole code again somewhat like -fwhole-program but from GIMPLE
opcodes).
Since it recompiles everything again, the optimization options have effect on
the result. If you don't specify -O on linker command line (which is useless in
the traditional usage mode), you'll get an absolutely unoptimized executable.
I think the optimization options should be either stored into the object files,
or maybe at least WRITE A BIG RED WARNING in the manual about it. I'm doing
embedded code and was shocked of the "quality" of the code... then I objdump'ed
the object file and have seen a totally different code - clean and optimized. I
almost pulled all my hair off till I realized it was the -flto switch that I
monkey-copied from someone else's makefile and after reading the description in
the manual I decided it "is a good thing".
The attached scripts demonstrate the bug. Comment out the -flto LDFLAGS switch
and the .s output gets optimized, uncomment and it gets unoptimized.
