[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