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.
