From: Borislav Petkov <bp@alien8.de>
To: Michael Matz <matz@suse.de>
Cc: Mauricio Faria de Oliveira <mfo@igalia.com>,
Richard Biener <rguenther@suse.de>,
Thomas Gleixner <tglx@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
Juergen Gross <jgross@suse.com>,
Alexey Dobriyan <adobriyan@gmail.com>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Jan Beulich <jbeulich@suse.com>, Brian Gerst <brgerst@gmail.com>,
kernel-dev@igalia.com, linux-kernel@vger.kernel.org,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()
Date: Wed, 2 Sep 2026 16:58:24 -0700 [thread overview]
Message-ID: <20260902235824.GFapi4ICSFCUiPSWVG@fat_crate.local> (raw)
In-Reply-To: <57b0d188-b256-bde4-43e6-99dae4f59d60@suse.de>
On Wed, Sep 02, 2026 at 03:29:44PM +0200, Michael Matz wrote:
> Strictly speaking, on x86, the '=@ccXY' constraints are register outputs
> into normal random integer registers (though they are of course
> initialized in a funny way), while the 'cc' clobber is not a register at
> all, but rather a fuzzy idea of "state" in old cc0-based compilers (which
> the x86 backend isn't anymore since, ... well, about forever, 1999). As
> such they both really don't conflict and ...
>
> > But then I'd expect that gcc would enforce that. I know it can't have it
> > when the clobbers contain input or output regs:
> >
> > In function ‘__memcmp’,
> > inlined from ‘main’ at memcmp.c:25:6:
> > memcmp.c:11:9: error: ‘asm’ operand has impossible constraints or there are not enough registers
> > 11 | asm volatile("test %3, %3\n\t"
> > | ^~~
> >
> > but with "cc" clobbers it works.
>
> ... hence there's nothing to report.
Aaaha, so the enforcement is solely documentation-based. :-)
> In fact what an explicit 'cc' clobber once meant in cc0 backends (that
> indiscriminated flag "state") is manufactured by the non-cc0 backends (all
> of them now) automatically whenever an asm has no flag output constraints at
> all. (On x86 that means it adds the "flags" register (internal name for the
> collection of flag status bits) to the clobber set automatically when there
> are no =@ccXY constraints).
>
> You can regard all 'cc' clobbers as pure source compatibility, they have
> no meaning anymore. But as they are so ubiquitous (even in our own docu),
> they remain recognized.
Ah ok, I see. so we'll simply forget them.
Thanks Micha!
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2026-09-02 23:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-22 18:33 [PATCH v9 0/5] x86/pvh: fix unbootable VMs again (PVH + KASAN) Mauricio Faria de Oliveira
2026-08-22 18:33 ` [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp() Mauricio Faria de Oliveira
2026-09-01 13:16 ` Jan Beulich
2026-09-02 8:33 ` David Laight
2026-09-02 14:18 ` H. Peter Anvin
2026-09-02 2:31 ` Borislav Petkov
2026-09-02 13:29 ` Michael Matz
2026-09-02 13:48 ` Mauricio Faria de Oliveira
2026-09-03 0:01 ` Borislav Petkov
2026-09-03 0:07 ` Mauricio Faria de Oliveira
2026-09-03 0:39 ` Borislav Petkov
2026-09-03 8:40 ` David Laight
2026-09-02 23:58 ` Borislav Petkov [this message]
2026-08-22 18:33 ` [PATCH v9 2/5] x86/asm, x86/boot: expose inline memcmp() Mauricio Faria de Oliveira
2026-09-06 17:01 ` Borislav Petkov
2026-09-06 18:15 ` H. Peter Anvin
2026-09-08 18:04 ` Mauricio Faria de Oliveira
2026-09-08 19:32 ` Borislav Petkov
2026-09-08 21:06 ` Mauricio Faria de Oliveira
2026-09-08 23:16 ` H. Peter Anvin
2026-09-09 8:38 ` David Laight
2026-09-09 13:43 ` H. Peter Anvin
2026-09-08 17:57 ` Mauricio Faria de Oliveira
2026-08-22 18:33 ` [PATCH v9 3/5] x86/asm: group inline string functions Mauricio Faria de Oliveira
2026-08-22 18:33 ` [PATCH v9 4/5] x86/cpuid: fix unbootable VMs by really inlining memcmp() in hypervisor_cpuid_base() Mauricio Faria de Oliveira
2026-08-22 18:33 ` [PATCH v9 5/5] x86/pvh: fix unbootable VMs by really inlining memset() in xen_prepare_pvh() Mauricio Faria de Oliveira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260902235824.GFapi4ICSFCUiPSWVG@fat_crate.local \
--to=bp@alien8.de \
--cc=adobriyan@gmail.com \
--cc=boris.ostrovsky@oracle.com \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jbeulich@suse.com \
--cc=jgross@suse.com \
--cc=kernel-dev@igalia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matz@suse.de \
--cc=mfo@igalia.com \
--cc=mingo@redhat.com \
--cc=rguenther@suse.de \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®