This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer



------- Comment #25 from Martin dot vGagern at gmx dot net  2006-08-10 21:48 -------
(In reply to comment #8)
> 1. No way we can support clobbering both SP and FP.

You could in theory by storing one of them to some fixed memory location. But
here things get really ugly, so this is more of a philosophical answer.

> 2. We could support clobbering the FP by pushing it onto the stack and
>    restoring it. Doesn't seem worth the trouble, though, since people can
>    do this themselves in the asm.

Not necessarily. For x86 with -fomit-frame-pointer, local variables are usually
adressed relative to SP. If you push FP onto the stack, you modify SP, and
operands are prehaps no longer accessible. If gcc would store FP on the stack,
it could take the offset into account and make things work.

By the way, the same is imo true for the x86 PIC register ebx, which I would
like to see clobberable and stored by gcc as well. Saving and restoring ebx in
asm can be a real pain for the above reason. It would be great if the compiler
additionaly would ensure that no other operand is an address relative to ebx.

> 3. We could support clobbering the SP by introducing a FP and being very
>    careful. I cannot see any useful application though, so it doesn't seem
>    worth the trouble.

One useful application would be in the sense of "no clobber register may
overlap with any of the other operands". You could place the SP on the clobber
list to indicate that you are going to modify it, and gcc could then try to
avoid emitting SP-relative operands, e.g. by making them FP-relative or
shouting if this is not possible.

You might even think of this in the sense of "a clobbered register may contain
any data at the end of the asm". That would be asm code that uses the stack,
but  does not clean up afterwards. You could in many cases restore the SP as a
fixed offset from the FP, to allow such asm code.

BTW: The test case I just wrote for bug 28686 exhibits this problem here as
well, along with two other issues.


-- 

Martin dot vGagern at gmx dot net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Martin dot vGagern at gmx
                   |                            |dot net


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]