https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #48 from Xi Ruoyao <xry111 at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #47) > 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. Currently Glibc returns the produced NaN (and there will be no IPA involved as the TU only contains one function, and AFAIK Glibc just does not support building with LTO). Is it enough to preserve the computation?
