On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
<rdsandif...@googlemail.com> wrote:
> Hi,
>
> Sorry in advance if this going over old ground. And if not, sorry
> for the somewhat negative message ;), but ... I think the current
> documentation and/or behaviour of the "optimize" attribute are a little
> confusing.
>
> The current behaviour is that, if __attribute__((optimize(...))) does
> not specify an optimisation level (-Ox), we act as though the prevailing
> -Ox level had been restated. So:
>
> __attribute__((optimize("no-gcse")))
>
> behaves like:
>
> __attribute__((optimize("Ox", "no-gcse")))
>
> where Ox is the current optimisation level. This means that if you
> compile:
>
> void bar (int);
> void __attribute__((optimize("no-gcse"))) f1 (void)
> {
> bar (1);
> bar (2);
> }
> void f2 (void)
> {
> bar (1);
> bar (2);
> }
>
> with -O2 -fno-omit-frame-pointer, f1 will be implicitly use:
>
> __attribute__((optimize("O2", "no-gcse")))
>
> and this implicit -O2 will override the explicit -fno-omit-frame-pointer.
> So f1 will be compiled without a frame pointer but f2 will be compiled
> with one.
>
> Is this really what we want? If so, I think it's subtle enough to be
> worth documenting. It certainly isn't what I was expecting after
> reading the current documentation.
IMHO this is a bug. And IMHO this optimize attribute went way over what was
reasonable to implement as a start - leading to all of these
interesting problems.
Richard.
> Richard
>
