Segher Boessenkool <seg...@kernel.crashing.org> writes:
> Hi!
>
> On Sat, Mar 20, 2021 at 10:53:32AM -0400, Vladimir Makarov via Gcc-patches
> wrote:
>> It seems CONSTRAINT_LEN treats constraint '\0' as one having length 1.
>
> Maybe we should fix that? See attached patch.
I don't strongly object, but CONSTRAINT_LEN (0) doesn't feel to me like a
question we should be asking. IMO it would be confusing to have, say:
p += CONSTRAINT_LEN (*p);
“stick” at a null terminator even though the code is notionally
an increment.
'\0' is just a normal string null terminator and so I don't think we
should be processing it as if it were a constraint character.
How about having a gcc_unreachable on zero instead?
Thanks,
Richard
> Segher
>
>
> diff --git a/gcc/genpreds.c b/gcc/genpreds.c
> index 8499a2a2383b..b83a030d6a5d 100644
> --- a/gcc/genpreds.c
> +++ b/gcc/genpreds.c
> @@ -1141,6 +1141,9 @@ write_insn_constraint_len (void)
> " switch (fc)\n"
> " {");
>
> + /* Empty constraints have length 0. */
> + printf (" case 0: return 0;\n");
> +
> for (i = 0; i < ARRAY_SIZE (constraints_by_letter_table); i++)
> {
> class constraint_data *c = constraints_by_letter_table[i];
> @@ -1470,14 +1473,9 @@ write_tm_preds_h (void)
> address_start, address_end);
> write_allows_reg_mem_function ();
>
> - if (constraint_max_namelen > 1)
> - {
> - write_insn_constraint_len ();
> - puts ("#define CONSTRAINT_LEN(c_,s_) "
> - "insn_constraint_len (c_,s_)\n");
> - }
> - else
> - puts ("#define CONSTRAINT_LEN(c_,s_) 1\n");
> + write_insn_constraint_len ();
> + puts ("#define CONSTRAINT_LEN(c_,s_) insn_constraint_len (c_,s_)\n");
> +
> if (have_register_constraints)
> puts ("extern enum reg_class reg_class_for_constraint_1 "
> "(enum constraint_num);\n"
