[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608

--- Comment #19 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 10 Jan 2023, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
> 
> --- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> See #c10, I think even with comparisons we need to be careful.  One thing is
> whether we can prove one of the branches will be unreachable, we can do that
> and replace that branch with __builtin_unreachable, but if trapping math is on,
> if a comparison is possibly trapping (operands could be NAN as checked by
> frange) or if it is the last use of some SSA_NAME that needs to be kept live
> because its computation is possibly trapping, I think we need to preserve the
> comparison.
> One question is if the default -ftrapping-math should cover all exceptions or
> just the some subset, invalid/overflow are the worst ones, then underflow and
> least importance is inexact IMHO, pretty much anything can be inexact...

I suppose similar to -fdelete-dead-exceptions with EH we need some
-fdelete-dead-traps (that's bad wording) and at least have that on by
default.  I think the standard mandates #pragma FENV_ACCESS on if you
want to inspect the IEEE exception state, and our defaulting mix
(-ftrapping-math but -fno-rounding-math) doesn't make sense in this
respect and the documentation is not clear (or my english is bad) here:

"This command-line option
will be used along with @option{-frounding-math} to specify the
default state for @code{FENV_ACCESS}."

How does "along with" specify how the "default state for FENV_ACCESS"
is "computed"?