[Bug middle-end/108799] Improper deprecation diagnostic for rsp clobber

[pskocik at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799

Petr Skocik  changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #3 from Petr Skocik  ---
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?

[Bug middle-end/108799] Improper deprecation diagnostic for rsp clobber

[andrew.cooper3 at citrix dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799

--- Comment #2 from Andrew Cooper  ---
Adding a memory clobber doesn't make any difference that I can see, and I'm not
aware of any reason why it ought to make a difference.

I suppose that my real request here is to figure out what is the correct way to
indicate that the redzone is clobbered, and to document it.

[Bug middle-end/108799] Improper deprecation diagnostic for rsp clobber

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108799

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Keywords||documentation

--- Comment #1 from Andrew Pinski  ---
I suspect:

  asm volatile ("pushf; popq %[fl]"
: [fl] "=r" (fl)
   , "+r" (rsp)
:
: "memory"
  );

Will fix the issue in the inline-asm; this is just a documentation issue I
think.