------- Comment #8 from wvangulik at xs4all dot nl 2007-11-05 22:48 -------
(In reply to comment #7)
> With Mike's description in comment #6, confirmed on 4.1.2 and 4.2.2. AVR GCC
> 4.2.2 is worse than 4.1.2, in that even if sub2 is called with (x+1), the
> variable is still 16 bits.
>
There is something more going on, this is the assembler output when sub2 is not
in the same file, and calling sub2(x), i.e not x+1:
===================================================================
push r17
push r28
push r29
in r28,__SP_L__
in r29,__SP_H__
sbiw r28,1
in __tmp_reg__,__SREG__
cli
out __SP_H__,r29
out __SREG__,__tmp_reg__
out __SP_L__,r28
/* prologue end (size=11) */
.L3:
sts x.1261,__zero_reg__
ldi r24,lo8(0)
.L4:
ldd r17,Y+1
call sub2
add r17,r24
std Y+1,r17
lds r24,x.1261
subi r24,lo8(-(1))
sts x.1261,r24
sbrs r24,7
rjmp .L4
rjmp .L3
===========================================================
Note that x is now living in memory (as one would expect when it's static in a
function). However it's not when looking at the original report. Is this ok?
The original post assembler places x in r14,r15. Does this still adhere the
static keyword? I don't know, since it's value is always set at the start
what's the point of being static? Unless main is called twice? But then x may
not be in r14/r15!
So it seems to me this is some inline optimation problem.
Note that moving the sub2 function above main also gives other results?!? Is
this standard behaviour?
Also note that when making sub2 static will completely remove it but also
remove x as static, is this allowed?
Tested against avr-gcc 4.1.2
--
wvangulik at xs4all dot nl changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |wvangulik at xs4all dot nl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33970
