I tested with debian jessie's gcc 4.9.1-19 targeting x86_64 and I agree
in general with Chaoran Yang's findings. Specifically, optimize(1)
doesn't imply -fomit-frame-pointer .. and optimize(0) doesn't impliy
-fno-omit-frame-pointer. optimize("O1"), optimize(2) and so on seem to
continue this pattern.
I disagree with Jonathan Wakely's response that only more complicated
functions should be considered: to assess whether the omit-frame-pointer
optimization is being applied, a very simple function such as 'int foo()
{ return 2; }' is quite useful.
I agree with the other commenters that it's important to follow the
documentation of __attribute__((optimize)) closely. When examples have
errors, such as saying optimize("-fomit-frame-pointer") rather than the
correct optimize("omit-frame-pointer"), or even worse when the examples
are written with "smart quotes", it's too easy to attribute what is
being seen to an error by the reporter. (however, my gcc seems to treat
these nonsense arguments to optimize() as errors so probably the OP had
them right in test code if not in the messages on this mailing list)
This may be related to bug #37565 --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565 -- in which gcc
doesn't properly manage the interplay between
optimize(2,"omit-frame-pointer") and -mno-accumulate-outgoing-args.
(though https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38716 reports that
an (implict!) optimize("O2") is spuriously reenabling
-fomit-frame-pointer in gcc 4.4, so perhaps this behavior has changed
over gcc's history)
As for the original situation, if -fomit-frame-pointer is important in
the generated code, it can be separately specified in optimize(). In my
testing, this seemed to work as expected.
I did most of my testing by building
void foo() {}
__attribute__((optimize(1)))
void goo() {}
__attribute__((optimize(0)))
void hoo() {}
__attribute__((optimize("omit-frame-pointer")))
void woo() {}
with commandlines similar to
gcc -Wall -O -S -o- booboo.c | grep -v '^\s*\.'
to look at uncluttered assembly.
Jeff
