On Fri, Jan 2, 2009 at 4:05 AM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> 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.
>
Also see:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
--
H.J.
