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

[Erik Christiansen]

On Wed, Oct 28, 2009 at 04:51:23PM +0100, David Brown wrote:
> Was this from a mail from Joerg Desch that did not make it to the mailing 
> list?  It is hard for others to comment - perhaps you or Joerg could 
> re-post the problem code.

Checking, I find that the mail was "To: address@hidden" and
CCed to me. If it didn't reach the list, then I'm not the only one who
has had mails swallowed silently. (Ah, I'd thought it was just my
filtering of duplicate mails which left me with only the direct copy,
but I see now that a list copy was not received.)

> Erik Christiansen wrote:
>> Ah, yes, optimisation needs to be used for inline to work. If the above
>> fails on a small test case, "avr-gcc -v" and the command-line don't show
>> a lurking "-fno-inline", and "-Wall -Wextra" doesn't provide any clues
>> either, I'd pretty soon be tempted to report it as a bug, unless a magic
>> method is revealed on the list. You've probably tried other
>> optimisations? (Just in case the size optimisation is absolute in its
>> approach.)
>
> I believe you need the -Winline to get a warning about functions declared 
> "inline" that could not be inlined.

The extremes apparently needed to achieve a genuine and complete -Wall
seem to gradually increase. Thanks for the "heads up".

> And an __attribute_((always_inline)) function will be inlined, regardless 
> of the optimisation levels.

Oh-oh, I do need to update. My avr-gcc is still 4.2.1, and the manpage
still says:

"Note that if you are not optimizing, no functions can be expanded inline"

but the current
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Function-Attributes.html#index-g_t_0040code_007balways_005finline_007d-function-attribute-2190

clarifies:

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. 

Erik