On Sun, Jun 28, 2026 at 09:37:31PM +0200, Georg-Johann Lay wrote:
> Am 28.06.26 um 14:25 schrieb Stefan Schulze Frielinghaus:
> > From: Stefan Schulze Frielinghaus <[email protected]>
> >
> > This is a follow-up to
> > https://gcc.gnu.org/pipermail/gcc-patches/2026-May/717805.html
> > with the following changes:
> >
> > - Make usage of uninitialized register asm input operands undefined by
> > removing the hack during gimplify_asm_expr() and document it as
> > undefined.
> > - Remove redundant helper stmt.cc:rclass_entails_registers and use
> > existing function in_hard_reg_set_p instead which computes the same.
> > - Add testsuite/gcc.dg/asm-hard-reg-strict-6.c in order to test for an
> > uninit diagnostics. Of course, in case of -fno-strict-extended-asm
> > -Wstrict-extended-asm -W{maybe-,}uninitialized we still don't get a
> > diagnostics.
> >
> > Cheers,
> > Stefan
> >
> > -- 8< --
> >
> >
> > [...] In order to automatically rewrite register asm into hard register
> > constraints, it is crucial that the register referred to by the register
> > asm operand is entailed in the register class of the corresponding
> > constraint of the operand. If this is not the case, then error out in
> > case of -fstrict-extended-asm, or in case of -fno-strict-extended-asm
> > -Wstrict-extended-asm emit a diagnostics.
>
> I don't really understand what that means...
>
>
> Does it mean there are restrictions to which types may be used
> in multi-register register asm or hardreg constraints?
> For example, when a register asm spans more than one register class?
This basically means that if the registers referred to by the register
asm operand are not entailed in the register class referred to by the
corresponding constraint, then this is considered an error. For an
example, see gcc/testsuite/gcc.dg/asm-hard-reg-strict-{1,2}.c
Cheers,
Stefan
>
> Johann
>
>
