https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608
--- Comment #50 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 27 Jan 2023, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 > > --- Comment #49 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #47) > > > Glibc already changed the code from Inf/Inf to (x - x) / (x - x) where x > > (x - x) / (x - x) is 0 / 0, not Inf / Inf. > Anyway, for frange potential in GCC 14, I'd hope we do figure out that > x - x has [0, 0] range (never -0.0 even, unless -frounding-math where it could > be -0.0 when rounding to -Inf) provided x is known to be finite - > all of Inf - Inf, (-Inf) - (-Inf) and NaN - NaN are NaN. > And frange already has an infrastructure for that, foperator_minus::rv_fold is > passed relation_kind between op1 and op2, so if it is VREL_EQ and we can check > that Inf or NaN isn't possible in the range, we should yield [0, 0]. > Or for -ffast-math do it always and yield [-0., 0] as Inf/NaN aren't expected > but signed zeros are present but are insignificant. > Shall we file a PR for that? > > > > 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)); > > In this case I guess that is at least right now fine (and glibc I think even > has a macro for that, some math_*). The thing is that the result is NaN and > we > don't treat NaN as singleton (because there are many representations of NaN). > Similarly the workaround for fold-overflow-1.c added in this PR will not treat > for now > operations from finite operands yielding singleton Inf or -Inf as singleton. > But if it is something else, say finite + finite and the expectation is that > inexact is raised, then the above wouldn't help, because we'd just turn it > into > "g" (constant) > in the asm. For inexact yes, but we do refrain from constant folding when that loses exceptions (in some cases at least), not just when it produces a NaN.
