On Tue, Jan 13, 2026 at 08:03:48AM -0700, Jeffrey Law wrote:
>
>
> On 1/12/2026 1:38 AM, Stefan Schulze Frielinghaus wrote:
> > From: Stefan Schulze Frielinghaus<[email protected]>
> >
> > With the current implementation, for an alternative like {r0}{r1}...{rn}
> > the last hard register constraint {rn} would always win which is not
> > what users expect. Therefore, error out in case of multiple hard
> > register constraints in one alternative.
> >
> > As far as I can tell right now, there is no inherent problem with
> > supporting multiple hard register constraints in one alternative or even
> > ad-hoc register classes. However, in light of reaching stage 4, this is
> > something for another release.
> >
> > Likewise, a combination of hard register constraints and regular
> > register constraints is not supported. Note, a combination of hard
> > register constraints and non-register constraints as e.g. immediate
> > constraints is supported. This is inspired by the i386 target where
> > constraints like aI are used which could be expressed as {ax}I, too.
> >
> > gcc/ChangeLog:
> >
> > * stmt.cc (parse_output_constraint): Reject multiple hard
> > register constraints or a combination of hard register
> > constraints and regular register constraints in one alternative.
> > (parse_input_constraint): Ditto.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.dg/asm-hard-reg-error-1.c: Remove tests containing
> > multiple hard register constraints in one alternative.
> > * gcc.dg/asm-hard-reg-error-6.c: New test.
> > ---
> > Bootstrapped and regtested on s390 and x86_64. Ok for mainline?
> Yea. Given the infrastructure you've built I think most if not all of what
> would be needed to specify a small set of explicit registers ought to work,
> even if that set of registers doesn't correspond to a register class.
>
>
> Do you need to update extend.texi at all to document these cases are syntax
> errors?
>
>
> OK with the doc update (if needed). If the docs are already clear on this,
> then the patch is OK as-is.
I don't mention the possibility of multiple constraints in one
alternative in the docs at all. I refrained from that in the beginning
since I haven't done extensive testing here. As presented at the
Cauldron I used the i386 target and replaced every single register
constraint a,b,c,d,S,D with the corresponding hard register constraint
in the machine description for testing. This included quite a bunch
like {ax}I etc. Bootstrap and regtest went fine. Though, this is all
testing I have done beside some artificial ones. So far I have focused
primarily on fixing issues which prevent the usage of hard register
constraints in alternatives with a single constraint.
I added to the subsubheading Limitations in extend.texi the following to
make at least clear what is not supported:
"Multiple hard register constraints in one alternative are also not supported.
Furthermore, combinations of hard register constraints and regular register
constraints in one alternative are not supported, too."
Thanks,
Stefan