https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Aldy Hernandez from comment #9)
> (In reply to Jakub Jelinek from comment #4)
> > I see fold_using_range::relation_fold_and_or
> > which sees relation1 VREL_LE and relation2 VREL_GE and !is_and, and because
> > of
> > relation_union (relation1, relation2) == VREL_VARYING fold it to 1.
> > But for floating point comparisons, LE | GE is not always true, it is true
> > if
> > neither operand is NAN, otherwise false.
>
> Ah, it was the union not the intersect. So we need something here that
> would avoid resolving this to 1 if maybe_isnan() is true for either source
> operand.
One possibility would be to separate integral/pointer and floating point
relations,
use VREL_FP_LE etc. (and have more of them to cover even the extra ones).
Another would be based on whether it is a floating point relation or
integral/pointer relation use different relation_{intersect,union}, or pass
those functions a bool flag whether it is floating point or not (well, to be
precise, if NANs aren't honored, we can treat even floating point comparisons
as integral/pointer ones).
If we keep VREL_LE etc. for both floating point with NAN and other relations,
I'd think we should treat them as the floating point <= etc. comparisons with
their meaning for NANs operand if any. And then go through the intersect/union
tables and think about each case whether it holds even for NANs or not. I
assume most of the cases would be the same. Say <= intersected with >= is
really ==. But e.g. <= unioned with >= is not VREL_VARYING (the question is
what to return in that case though, VREL_LAST as some way to express
VREL_UNKNOWN?).
BTW, with the additions of VREL_PE*, the intersect/union tables grew quite a
lot but contain 0 (aka VREL_VARYING) in those extra slots. Does it make sense
to include VREL_PE* in those tables at all when it isn't really meaningful?
