https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #46 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- (In reply to Richard Biener from comment #45) > (In reply to Xi Ruoyao from comment #44) > > (In reply to rguent...@suse.de from comment #43) > > > 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? > > I think we should adjust the testcase with a volatile like I suggested above > so we verify that we don't eliminate the computation with a "constant" NaN. Ok, I'll post a patch. Glibc already changed the code from Inf/Inf to (x - x) / (x - x) where x is not a constant, but I'm wandering if the compiler will attempt to optimize out (x - x) / (x - x) later... Is it possible to provide a "__builtin_feraiseexcept" so we'd be able to use it instead of the nasty (x - x) / (x - x) to raise the exception?
