[committed] [PR99454] LRA: Process 0..9 constraints in process_address_1

Jakub Jelinek jakub@redhat.com
Tue Mar 9 14:26:12 GMT 2021


On Tue, Mar 09, 2021 at 09:12:36AM -0500, Vladimir Makarov via Gcc-patches wrote:
> diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
> index 76e3ff7efe6..feff766c590 100644
> --- a/gcc/lra-constraints.c
> +++ b/gcc/lra-constraints.c
> @@ -3452,6 +3452,10 @@ process_address_1 (int nop, bool check_only_p,
>  
>    constraint
>      = skip_contraint_modifiers (curr_static_id->operand[nop].constraint);
> +  if ('0' <= constraint[0] && constraint[0] <= '9')

Yoda conditions?

Anyway, more importantly, the docs say:
     If multiple
     digits are encountered consecutively, they are interpreted as a
     single decimal integer.  There is scant chance for ambiguity, since
     to-date it has never been desirable that '10' be interpreted as
     matching either operand 1 _or_ operand 0.  Should this be desired,
     one can use multiple alternatives instead.
so, doesn't this need to use
    {
      char **end;
      unsigned long dup = strtoul (constraint, &end, 10);
      constraint
	= skip_constraint_modifiers (curr_static_id_operand[dup].constraint);
    }
instead?
Otherwise, if you have (even large) testcase that misbehaves with 0-9
dups, it should be possible to create one with 10-30?

> +    constraint
> +      = skip_contraint_modifiers (curr_static_id->operand
> +				  [constraint[0] - '0'].constraint);
>    cn = lookup_constraint (constraint);
>    if (insn_extra_address_constraint (cn)
>        /* When we find an asm operand with an address constraint that


	Jakub



More information about the Gcc-patches mailing list