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.
