[Bug target/51002] SP_H register is used even on targets that do not have it (eg attiny26)

["gjl at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51002

--- Comment #7 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-18 20:12:43 UTC ---
(In reply to comment #6)
> Jut a comment: at least I was using -mtiny-stack on targets with 16-bit stack
> to reduce the size of the prologue/epilogue of a function. This worked quite
> well, of course only if the actual stack usage really stayed below 256 bytes.

I don't think that works reliably, even if the stack usage is below 256 bytes.
Crucial point is the crossing of a 256-byte boundary, i.e. changing SP.H, for
example while crossing the 0xff/0x100 border.

As there is code in libgcc that has to set the frame pointer, it has to load
the high byte of FP, too. libgcc (just as gcc) assumes that SP.H is always
zero.

Otherwise, the multilibs had to be split even further, i.e. not only on basis
of SP size but also on basis of RAM size.

> With this "fix" this is no longer possible, because now the prologue only
> loads the lower 8 bits of the stack pointer into the _frame_pointer_.

As written above, the high byte of FP must be initialized, too. There is no
other meaningful value than 0 for 8-bit FP devices.

> Then the frame-pointer will refer the wrong address region.
> As a hack-around I'm using (in my own hacked gcc-4.7 version)

Maybe the startup-code from AVR-Libc has to be adapted to initialize SP with
0xff instead of with RAMEND, see

http://savannah.nongnu.org/bugs/?35407#comment3

> avr_current_device->short_sp instead of AVR_HAVE_8BIT_SP
> 
> to decide whether to load SP_H or not into the frame-pointer.