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.
jeff
