http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47658
--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-02-09
20:12:20 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > It works for me,
>
> what do you mean by "works" ?:)
works as "expected" ;) At -Os we inline to remove abstraction penalty
which usually causes code size savings. More inlining in 90% of all
cases increases code-size. As we can't really know at the time of
inlining whether we will hit the remaining 10% (without doing both
inlining and not inlining and later throwing away the larger variant)
we choose the heuristics that usually produce the smallest possible code.
> > the abstraction is completely eliminated by early inlining.
> > At -Os we do not inline E::foo2 into E::foo1 but that isn't abstraction and
> > it isn't easily visible that this is profitable. That results in the
> > -Os code being around 10% larger than -O2 code.
>
> and this imho is the problem. As -Os suggests, code should be as small as it's
> posiible. So i expect that if I use Os, the code will be the smallest that gcc
> can produce. However in this example I have to use -O2 or even -O3 to get the
> smallest code, and it's misleading.
But expected - perfection is not achievable here.
So to say, this bug is either WORKSFORME (as expected) or WONTFIX (aka,
it's impossible to generate the "smallest possible").
Citing the documentation:
@item -Os
@opindex Os
Optimize for size. @option{-Os} enables all @option{-O2} optimizations that
do not typically increase code size. It also performs further
optimizations designed to reduce code size.
It says "Optimize for size", not "Produce smaller code than -O2 or -O3
in all cases".
