[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c

["rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>]

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 rguenther@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.