https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I went through the whole rr_{intersect,union}_table tables and I think just
--- gcc/value-relation.cc.jj 2023-01-02 09:32:42.088000605 +0100
+++ gcc/value-relation.cc 2023-01-19 16:20:06.490126901 +0100
@@ -115,7 +115,7 @@ relation_kind rr_union_table[VREL_LAST][
{ VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING, VREL_VARYING,
VREL_VARYING, VREL_VARYING, VREL_VARYING },
// VREL_UNDEFINED
- { VREL_VARYING, VREL_LT, VREL_LE, VREL_GT, VREL_GE, VREL_UNDEFINED,
+ { VREL_VARYING, VREL_UNDEFINED, VREL_LT, VREL_LE, VREL_GT, VREL_GE,
VREL_EQ, VREL_NE },
// VREL_LT
{ VREL_VARYING, VREL_LT, VREL_LT, VREL_LE, VREL_NE, VREL_VARYING, VREL_LE,
is really wrong for the integral/pointer relations (plus the question what to
do with the VREL_PE* relations and whether they need to be in the tables or
punted on by the caller somehow).
Now, when considering the relations in the fp with NAN meaning they have in
C/C++
(and assuming we don't try to replace say two actual comparisons in the IL with
one
with different exception behavior), the only relations in the tables which are
true for unordered operand(s) are VREL_VARYING and VREL_NE. Maybe I miss
something, but I can't think of an inappropriate intersection - VREL_VARYING
intersects anything is anything,
VREL_VARYING intersect VREL_VARYING is the only one that gives VREL_VARYING,
VREL_{VARYING,NE} intersect VREL_NE or vice versa the only one that gives
VREL_NE
and VREL_UNDEFINED returned only from intersections of anything and
VREL_UNDEFINED, or
LT/LE/GT/GE vs. each other where there is no overlap (but in that case neither
allows NANs), LT/GT vs. EQ (ditto) and EQ vs. NE (one relation doesn't allow
NAN but the other does, so they aren't allowed.
As for unions - LT U GT or vice versa is incorrectly NE, should be LAST or LTGT
or some other way how to express we can't express it. LT U GE or LE U GT or LE
U GE or vice versa are incorrectly VARYING, when they are together ORDERED (so
again, need some way how to express that). Can't find anything else wrong.
But unless we use VR_UNKNOWN or VR_LAST or whatever to stand for something we
really don't know how to handle, we'd need the various combinations that
tree.def has on top of the basics, LTGT, UNORDERED, ORDERED, UNLT, UNLE, UNGT,
UNGE and UNEQ.
