avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[avr-gcc-list] Re: optimizer removes volatile pin access code.why?


From: David Brown
Subject: [avr-gcc-list] Re: optimizer removes volatile pin access code.why?
Date: Mon, 02 Nov 2009 09:29:22 +0100
User-agent: Thunderbird 2.0.0.23 (Windows/20090812)

Weddington, Eric wrote:


-----Original Message----- From: address@hidden [mailto:address@hidden org] On Behalf Of Joerg Wunsch Sent: Sunday, November 01, 2009 11:25 PM To: address@hidden Subject: Re: [avr-gcc-list] Re:
optimizer removes volatile pin access code.why?

David Brown <address@hidden> wrote:

It might be worth filing a report for a better clarification in
the documentation (does that need a bug report?) to make it
clearer that "always_inline" has no effect without a normal
"inline" declaration.

This is what the GCC 4.3.2 manual says:

always_inline Generally, functions are not inlined unless
optimization is specified. For functions declared inline, this
attribute inlines the function even if no optimization level was
specified.

So it does say "for functions declared inline". With this
description, the "always_inline" attribute is really affecting how
the optimization works, not how inlining works per se, i.e. one still
has to mark the function as "inline" for inlining to happen. The
always_inline attribute tells the optimizer to inline even at -O0,
which apparently is not the default behaviour.

As far as I have seen, the compiler has been working exactly as it says in the manual (quoted above). If anyone can post a code snippet and compiler flags that contradict that, then please do so!

Would it be reasonable to ask for a change in the documentation, since several people have been caught out by it? Alternatively, should we ask for __attribute__((always_inline)) to imply inline, or give a warning if it is used for a non-inline function? I certainly can't think of any situation where you would want always_inline but not normal inline.

mvh.,

David





reply via email to

[Prev in Thread] Current Thread [Next in Thread]