[Bug tree-optimization/108447] [13 Regression] glibc math/test-*-iseqsig failures

[aldyh at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447

--- Comment #14 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to rguenther@suse.de from comment #13)
> On Thu, 19 Jan 2023, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
> > 
> > --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > As a workaround in stage4, perhaps, but long term the relations make a lot of
> > sense even for floating point with NANs.  If you know <= relation between 2
> > vars and know the range of one of them, the other can be computed from it, ...
> 
> I think it makes more sense to fix the relation combining code, maybe
> simply disable that for FP as a workaround?

Yeah, the combining code definitely needs some tweaks.

Thinking out loud here...

It looks like we ignore relations in the various relation fold_range() methods
if NAN can be a possibility.  See how frelop_early_resolve() only looks at the
relation if the operands are !NAN.  So perhaps this is why we never used
validate_relation().

On the other hand, the op1_range methods *do* use the relations.  For example,
on EQ_EXPR (foperator_equal::op1_range), we clear NAN on the TRUE side because
equality could never happen if there was a NAN present (regardless of VREL_*). 
On the FALSE side we set_nan() only if VREL_EQ.

So we ignore the oracle's relations in fold_range() throughout, unless we're
sure !NAN, and use the oracle from op1_range.