https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115161
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jsm28 at gcc dot gnu.org
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Hongtao Liu from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > Any of the floating point to integer intrinsics if they have out of range
> > value (haven't checked whether floating point to unsigned intrinsic is a
> > problem too or not).
> > No matter if it is float or double (dunno if _Float16 too, or __bf16), and
> > no matter if it is scalar intrinsic (ss/sd etc.) or vector and how many
> > vector elements.
> > But, this isn't really a regression, GCC has always behaved that way, the
> > only thing that actually changed is that perhaps we can constant fold more
> > than we used to do in the past.
> > When not using intrinsics, IMNSHO we should keep doing what we did before.
>
> Can we restrict them under flag_trapping_math?
If we do that, we should do it on the fold-const.cc side as well. There we
fold it but add TREE_OVERFLOW flag in the overflow cases to the resulting tree,
whether it prevents folding or not during GIMPLE passes would need to be
figured out.
C23 in F.4 says:
If the integer type is bool, 6.3.1.2 applies and the conversion raises no
floating-point exceptions if the floating-point value is not a signaling NaN.
Otherwise, if the floating value is infinite or NaN or if the integral part of
the floating value exceeds the range of the integer type, then the "invalid"
floating-point exception is raised and the resulting value is unspecified.
Otherwise, the resulting value is determined by 6.3.1.4. Conversion of an
integral floating value that does not exceed the range of the integer type
raises no floating-point exceptions; whether conversion of a non-integral
floating value raises the "inexact" floating-point exception is unspecified.
That said, this change really won't help the backend which supposedly should
have the same behavior regardless of -fno-trapping-math, because in that case
it is the value
of the result (which is unspecified by the standards) rather than whether an
exception is triggered or not.
