Re: GCC 15 -fzero-init-padding-bits= option and redzone clobber

Hi!

On Sat, Nov 30, 2024 at 09:43:53AM -0800, Linus Torvalds wrote:
> On Sat, 30 Nov 2024 at 03:13, Segher Boessenkool
> <[email protected]> wrote:
> >
> > But of course, GCC assumes there is a properly set up stack
> > *everywhere*, it can in principle insert calls *anywhere*.  So these
> > asm constraints are totally superfluous anyway!
> 
> Well, I wish that were true. But we used your trick for a reason: it
> fixed a real and present issue.
> 
> So no. It's not superfluous. It's required.

It expresses a fact that is true always anyway.  But it is required
to get a *side effect*.  "It is a hack", if you want.

(And "is true always" means "is a requirement on any program", of course
a user can blatantly violate those rules by writing incorrect programs).

> Without that "add sp register as a a input/output reg", at least some
> versions of gcc did in fact put inline asm in places where the frame
> was not set up.

Yes.  And that was not a bug, either: nothing expressed that there has
to be a frame set up for this asm to work, so GCC felt free to make more
optimal code (or what it thought was more optimal code, or potentially
anyway; "could be more optimal code").

> You seem to imply that that may be a gcc bug, of course. Par for the
> course - we have had other odd things in inline asms (or around them)
> for other gcc bugs.

Nope, it is not a GCC bug when users expect things that were not
promised to them.

> We do have commentary in some of our commits to that "it's a gcc bug"
> effect, ie this commit message from "only" seven years ago states:
> 
>     With GCC 7.2, however, GCC's behavior has changed.  It now changes its
>     behavior based on the conversion of the register variable to a global.
>     That somehow convinces it to *always* set up the frame pointer before
>     inserting *any* inline asm.  (Therefore, listing the variable as an
>     output constraint is a no-op and is no longer necessary.)

I have absolutely no idea what "conversion of the register variable to
a global" would mean, so I cannot parse what this sentence is meant to
mean.

There are two kinds of register variable: global register variables, and
local register variables.  Global register variables are declared at
global scope, and local register variables are declared within a
function.  There obviously is no way the compiler could decide to make a
local register variable a global one (that would change semantics!), so
it probably means something else, but I have no idea what.

> So if it makes you feel any better, the trick now works for a
> _different_reason_. Just the existence of the global register variable
> seems to matter to those newer versions of gcc.

Yeah, and I don't see now.  If there was a full testcase I could take a
look :-)

> But we technically still support those older gcc versions that require
> the old format (we still support back to gcc-5.1, although IO think
> we're about to make the jump up to 8.1 based on staid enterprise
> distro people finally having left some of the ancient stuff behind).

Why 8.1?  8.5 was a bugfix release (in general, always require the
latest version in a release series, or recommend it at least: we cannot
fix any bug in older releases, but we can do new releases :-) )

> So we *may* be able to remove this hack, if gcc people can actually
> pinky promise that it's not required with anything newer than 8.1

The problem is still not completely clear to me.  Maybe some other GCC
people will do such a promise, but at least I won't.  Sorry.


Segher