https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99540
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
--- Comment #7 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to Jakub Jelinek from comment #6)
> As a fix maybe even better
> --- gcc/config/aarch64/aarch64.c.jj 2021-03-19 10:14:18.302936161 +0100
> +++ gcc/config/aarch64/aarch64.c 2021-03-19 13:33:35.367973092 +0100
> @@ -4639,7 +4639,7 @@ aarch64_add_offset (scalar_int_mode mode
> if (can_create_pseudo_p ())
> {
> rtx coeff1 = gen_int_mode (factor, mode);
> - val = expand_mult (mode, val, coeff1, NULL_RTX, false, true);
> + val = expand_mult (mode, val, coeff1, NULL_RTX, true, true);
> }
> else
> {
>
> I mean, for 2's complement target (GCC doesn't support any other), the
> difference between non-widening/highpart signed and unsigned multiplication
> is just in that flag_trapv case, for 64-bit x 64-bit -> 64-bit
> multiplication the result bits are identical whether it is signed or
> unsigned and that is the reason why we only have MULT in RTL and not SMULT
> and UMULT.
Yeah, this looks good to me, thanks. In this context (coming from
rtl rather than trees) there's really no sign to speak of, so the
choice of argument was probably pretty arbitrary. I didn't think
about the effect on flag_trapv.
I'll take the bug to test that and add a testcase.
