Optimize attribute and inlining

[David Brown]

On 26/07/2012 11:12, Richard Guenther wrote:
> On Wed, Jul 25, 2012 at 8:25 PM, David Brown <david.brown@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.Selvaraj@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.

And if these options are so broken, should they be marked as such in the 
manual?

Thanks for your time here.

David