Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re "naked."

[Bill Westfield]

> 1. If you complain of missed optimisations, you should post the command line 
> switches you have used, the -Ox switch at least.

Yes. Sorry.  Corrected recently.

> 2. Don't use the naked attribute if you don't understand its implications - 
> here, main uses stack frame which has not been created due to naked; this 
> might work only by coincidence (Y being set to a sane value in startup).

I noticed that; with 4.3.2 it optimizes ch in a register.  In 4.5.3 it
puts ch on the stack, even if I change the declaration to explicitly
ask for a register.  ("register" is supposed to be mostly a no-op
these days, right?  the register allocator is normally good enough
that you don't need to ask.  So, why isn't it here?  It's not like
there aren't quite a lot of spare registers...)  I was going to save
that question till later, or just deal with needing the stack frame,
which is "not unreasonable."


> 3. You should post the assembler output of compiler (which contains symbolic 
> labels) or relevant portions of disassembled elf, rather than disassembled 
> object with unresolved jump targets, which makes tracing the code difficult.

The example code doesn't link.  I didn't realize that the -S output
from the compiler was so different than what objdump generates; that
will be handy!

> 4. If you desire control over code size (and other aspects of the code too), 
> resort to assembler.

There is always that.  At the moment, optiboot is a "shining example"
of how the C compiler can generate output almost as small as
assembler, and "suitable for bootloaders" and such.  I tried to hit
the next size limit for bootloaders (256 bytes) in tricky assembler; I
don't think it's possible.  So till this, C has been "good enough."

But in this case, I think I have genuinely odd behavior that should be
explained, even if it can't be fixed.