On 26/07/2012 14:04, Richard Guenther wrote:
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
Fair enough - but will "gcc x.c -Os" with "#pragma Gcc optimize 3" as
the first line of "x.c" do the same thing as "gcc x.c -O3" ?
I realise that we can't get everything here. C in general, and gcc in
particular, is extremely flexible - there are always going to be ways to
cause trouble.
But while it is always best to write source code that works correctly
regardless of the optimisation levels, occasionally there is code with
special requirements. It might be code that should be optimised
particularly aggressively, or it might be code that should not be
optimised, or have other options (such as older code that breaks strict
aliasing rules). I think such requirements are best put in the C file
(as pragmas or attributes) rather than in a Makefile - it binds them
tighter to the code in question.
If the pragmas work as long as they come before any other code, then
that gives them a useful, though limited, purpose.
And if these options are so broken, should they be marked as such in the
manual?
Probably yes.
Or they could be fixed :-)
Could the pragmas be changed (or replaced) with ones explicitly designed
to override command-line options, regardless of where they appear in the
order in the file? Of course, you are still going to get conflicts when
someone specifies more than one c file on the command line, each of
which contains such overrides - I think the reasonable thing to do this
is just exit with an error message.
Thanks for your time here.
David
