From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9415917BD3 for ; Sat, 30 Nov 2024 22:22:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=63.228.1.57 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733005325; cv=none; b=gYBWqcsUn1QO9+Vy18+neIus+RhMd6i49xQlB+0n906pRU7UkbQMUTX38NZ0wFbWJ/l35oCji+fQ3hnx+8gZQZ7fQL+2UN7RooI0Ww718yE5pwEW1nUbXGzPb4J93NX/nXTjhqTyjECjpuDhtltKqkVwwIIm0DEMiwEGdHGVYTM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1733005325; c=relaxed/simple; bh=YfG3mOD0TAbF3XxgnQ1xgqtMMVzZoozZm4X/frByKZc=; h=Date:From:To:Cc:Subject:Message-ID:References:Mime-Version: Content-Type:Content-Disposition:In-Reply-To; b=s/LaVirOqkbMggdc1y1AVC7Jw2U7Nnj/MLUQeSz0Rcbz1T9nJ8P1KpQCULjWkN9jg8SMCZTwusjLpnRKvTxOrypdLAoh82SB+R6Cjn3mvYhjd7+RYfjXqXwZcLOMZfIBh6jxNvBS4xQiPsnvstkxgsOslTFnhwx4zHf1vTwjmgY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org; spf=pass smtp.mailfrom=kernel.crashing.org; arc=none smtp.client-ip=63.228.1.57 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 4AUMJhOU025635; Sat, 30 Nov 2024 16:19:43 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 4AUMJfG0025633; Sat, 30 Nov 2024 16:19:41 -0600 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Sat, 30 Nov 2024 16:19:40 -0600 From: Segher Boessenkool To: Linus Torvalds Cc: Jakub Jelinek , Peter Zijlstra , linux-toolchains@vger.kernel.org, x86@kernel.org Subject: Re: GCC 15 -fzero-init-padding-bits= option and redzone clobber Message-ID: <20241130221940.GS29862@gate.crashing.org> References: <20241129125238.GI24400@noisy.programming.kicks-ass.net> <20241130111040.GR29862@gate.crashing.org> Precedence: bulk X-Mailing-List: linux-toolchains@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Hi! On Sat, Nov 30, 2024 at 09:43:53AM -0800, Linus Torvalds wrote: > On Sat, 30 Nov 2024 at 03:13, Segher Boessenkool > 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