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.
And if these options are so broken, should they be marked as such in the
manual?
Thanks for your time here.
David
