[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

Georg-Johann Lay <gjl at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dmixm at marine dot
                   |                            |febras.ru

--- Comment #9 from Georg-Johann Lay <gjl at gcc dot gnu.org> 2012-03-18 21:37:43 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > (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.
> 
> It should work reliably if the stack-top is aligned to a 256 bytes,

No, that's not sufficient. The reason is that gcc does not only change
SP. In some situations the cmopiler has to set up a frame pointer and
build a 16-bit pointer. If the stack pointer in only 8 bits wide, there
is no other sensible value than 0.

SP.H is a reserved register so that libgcc cannot tell if accessing SP.H
is prohibited because SP.H is reserved or if hard SP is actually 16 bits
wide and accessing SP.H would be in order.

See __prologue_saves in ./libgcc/config/avr/lib1funcs.S

> which is the case for many devices, but of course one has to check
> this individually.
>
> > 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.
> 
> Yes. Exactly  this is the problem: when artificially restricting the
> stack-space to 256 bytes, then nevertheless the frame pointer high-byte should
> be initialized with the high-byte of the stack-pointer.

As written above there is no SP.H as the multilibs do not differenciate
between SP.H=reserved and SP.H=not reserved but never changes

> > 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.
> 
> No. When -mtiny-stack just restricts the stack usage to 256 bytes, then there
> is no need for additional multi-lib targets. The ABI is not affected. 
> 
> Prerequisites are:
> 
> - the application really does not need more than 256 bytes stack space
> - stack-top is aligned to 256 bytes
> 
> Then: during stack updates no carry will occur from SP_L to SP_H.

As written above: It's not only about changing SP.H, it's also about
initializing the 16-bit FP from an 8-bit SP.

> I can be wrong but I think in the beginning -mtiny-stack was just meant for
> this kind of optimization. There is also a related commit, which breaks the
> distinction between 8-bit hardware and
> -mtiny-stack-8-bit-restricted-stack-space, this was
> 
> http://gcc.gnu.org/viewcvs?view=revision&revision=150801

I think it's never a good idea to lie to the compiler.

Let's see what Dmitry writes concerning crt*.o for the case of fake 8-bit SP.

This should fix the problem and your code work smooth again.