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"?