https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108447
--- Comment #8 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #1) > This one started with r13-1933-g24012539ae3410174. > I think the problem is in: > > Folding statement: _3 = cmp1_10 & cmp2_11; > Not folded > Folding statement: if (_3 != 0) > Registering value_relation (x_8(D) <= y_9(D)) on (2->3) > Registering value_relation (x_8(D) >= y_9(D)) on (2->3) > Intersecting with existing (x_8(D) <= y_9(D)) to produce (x_8(D) == > y_9(D)) Updated. > and later > Folding statement: _1 = cmp1_10 | cmp2_11; > Relation adjustment: cmp1_10 and cmp2_11 combine to produce [irange] > _Bool [1, 1] > Queued stmt for removal. Folds to: 1 > > When NANs are honored, the above is not true for floating point comparisons. > x <= y and x >= y comparisons are signaling (if either operand is qNaN or > sNaN), x == y and x != y aren't (they only signal if either operand is > sNaN), and while *blink*. Woah. I did not know that. As Andrew mentions down thread, we had validate_relation() to verify whether a relation could be registered. So for example, given x == x, validate_relation() would be called at registration time and call the range-ops entry for EQ_EXPR, which would return false for this combo if x could be a NAN. For some forgotten reason, we forgot to call validate_relation() at the oracle's registry. My guess is that since we ignore the oracle's answers in frelop_early_resolve() (if !maybe_isnan) in each of the relational operators, it was no longer needed. Although for the testcase here, perhaps this would not have helped either. Is there anything in x_8 or y_9 that could be used indicate that we can't register these relations? <bb 2> : cmp1_10 = x_8(D) <= y_9(D); cmp2_11 = x_8(D) >= y_9(D); _3 = cmp1_10 & cmp2_11; if (_3 != 0) That is, when we see x_8 <= y_9, is there anything in either the range of x_8 or y_9 that would hint that we can't register the <= relation? I would have assumed that we could only register this relation if neither x_8 nor y_9 can have a NAN. Would this help? If this won't help, then perhaps the issue is in the oracle's relation intersection code. We would need a way to indicate that VREL_LE ^ VREL_GE is VREL_VARYING if the source operands may have a NAN (or some other fancy FP condition I don't understand ;-))?
