Documentation and behaviour of the "optimize" attribute

[H.J. Lu]

On Fri, Jan 2, 2009 at 4:05 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Fri, Jan 2, 2009 at 12:36 PM, Richard Sandiford
> <rdsandiford@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.
>

Also see:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565


-- 
H.J.