On Tue, Jun 27, 2023 at 8:56 AM Robin Dapp via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > > You can put it into the original one. > > Bootstrap and testsuite run were successful. > I'm going to push the attached, thanks.
I am reducing a bug report which I think will be fixed by this change (PR 110444). I will double check to see if this has fixed this issue once I finished reducing it. I will commit a testcase if this patch fixed the issue. Thanks, Andrew Pinski > > Regards > Robin > > diff --git a/gcc/match.pd b/gcc/match.pd > index 33ccda3e7b6..83bcefa914b 100644 > --- a/gcc/match.pd > +++ b/gcc/match.pd > @@ -7454,10 +7454,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT) > values representable in the TYPE to be within the > range of normal values of ITYPE. */ > (if (element_precision (newtype) < element_precision (itype) > + && (!VECTOR_MODE_P (TYPE_MODE (newtype)) > + || target_supports_op_p (newtype, op, optab_default)) > && (flag_unsafe_math_optimizations > || (element_precision (newtype) == element_precision > (type) > - && real_can_shorten_arithmetic (TYPE_MODE (itype), > - TYPE_MODE (type)) > + && real_can_shorten_arithmetic (element_mode > (itype), > + element_mode > (type)) > && !excess_precision_type (newtype))) > && !types_match (itype, newtype)) > (convert:type (op (convert:newtype @1) >
