https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #44 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #43) > On Thu, 19 Jan 2023, xry111 at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 > > > > --- Comment #42 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- > > (In reply to Richard Biener from comment #41) > > > We could fix the testcase with > > > > > > diff --git a/gcc/testsuite/gcc.dg/pr95115.c > > > b/gcc/testsuite/gcc.dg/pr95115.c > > > index 69c4f83250c..09273e445d2 100644 > > > --- a/gcc/testsuite/gcc.dg/pr95115.c > > > +++ b/gcc/testsuite/gcc.dg/pr95115.c > > > @@ -17,6 +17,7 @@ int > > > main (void) > > > { > > > double r = x (); > > > + volatile double rr = r; > > > if (!__builtin_isnan (r)) > > > abort (); > > > if (!fetestexcept (FE_INVALID)) > > > > > > that preserves optimizing the isnan check but also preserves the > > > computation > > > and checks the non-propagation of a NaN. > > > > Hmm, so it means we cannot rely on Inf / Inf to raise an exception? Then we > > need to fix Glibc... > > If the result is unused then no, GCC will happily elide exceptions from > unused computations like Inexact from the statement > > 1./3.; > > but this has been done before. What's new is that GCC can now elide > some uses (in this case the isnan check is the only use) The should we just change PR95115 to "INVALID" and remove the test case, and fix any regression on Glibc side?
