On Thu, Jul 26, 2012 at 1:21 PM, David Brown <da...@westcontrol.com> wrote:
> On 26/07/2012 11:12, Richard Guenther wrote:
>>
>> On Wed, Jul 25, 2012 at 8:25 PM, David Brown <david.br...@hesbynett.no>
>> wrote:
>>>
>>> On 25/07/12 17:30, Richard Guenther wrote:
>>>>
>>>>
>>>> On Wed, Jul 25, 2012 at 4:07 PM, Selvaraj, Senthil_Kumar
>>>> <senthil_kumar.selva...@atmel.com> wrote:
>>>>>
>>>>>
>>>>> Declaring a function with __attribute__((optimize("O0")) turns off
>>>>> inlining for the translation unit (atleast) containing the function
>>>>> (see output at the end). Is this expected behavior?
>>>>
>>>>
>>>>
>>>> Not really. The optimize attribute processing should only affect
>>>> flags it saves. -f[no-]inline is not meaningful per function and we
>>>> have the noinline attribute for more proper handling.
>>>>
>>>> That said, I consider the optimize attribute code seriously broken
>>>> and unmaintained (but sometimes useful for debugging - and only
>>>> that).
>>>>
>>>
>>> That's a pity. It's understandable - changing optimisation levels on
>>> different functions is always going to be problematic, since
>>> inter-function
>>> optimisations (like inlining) are going to be difficult to define. But
>>> sometimes it could be nice to use specific optimisations in specific
>>> places,
>>> such as loop unrolling in a critical function while other code is to be
>>> optimised for code size. Does "#pragma Gcc optimize" work more reliably?
>>
>>
>> No, it uses the same mechanism internally.
>>
>> Richard.
>>
>
> Is it reliable to use "#pragma Gcc optimize" options at the start of the
> file, as an alternative to specifying them in the command line? For
> example, a Makefile might specify "-Os" as standard options for all c files,
> but one particular file might have "#pragma Gcc optimize 3" at the start.
> If the line is at the start of the file, before any #includes or code, then
> there would be no mixing of optimisation levels.
Behavior will not be the same for
gcc -include foo.h x.c
when you change x.c in the proposed way compared to
gcc -include foo.h x.c -O3
> And if these options are so broken, should they be marked as such in the
> manual?
Probably yes.
> Thanks for your time here.
>
> David
>
