https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799
Petr Skocik <pskocik at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pskocik at gmail dot com
--- Comment #3 from Petr Skocik <pskocik at gmail dot com> ---
Very good question. The deprecation of SP clobbers could use some explanation
if there are indeed good reasons for it.
IMO, if listing the SP as a clobber both (1) forces a frame pointer with
frame-pointer-relative addressing of spills (and the frame pointer isn't
clobbered too) and (2) avoids the use of the red zone (and it absolutely should
continue to do both of these things in my opinion) then gcc shouldn't need to
care about redzone clobbers (as in the `pushf;pop` example) or even a wide
class of stack pointer changes (assembly-made stack allocation and frees) just
as long as no spills made by the compiler are clobbered (or opened to being
clobbered from signal handlers) by such head-of-the-stack manipulation. Even
with assembly-less standard C that uses VLAs or allocas, gcc cannot count on
being in control of the stack pointer anyway, so why be so fussy about it when
something as expert-oriented as inline assembly tries to manipulate it?
