https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #47 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 27 Jan 2023, xry111 at gcc dot gnu.org wrote: > 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? Not trivially. I'd suggest glibc uses a volatile use, like for example tem = Inf/Inf; __asm__ volatile ("" : : "g" (tem)); or so to preserve the computation and avoid an actual store to a volatile variable. Though I see at least GCC 7 optimizing the above division to a constant, lacking a fix we deployed later.
