https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #14 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to rguent...@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.
