From 67761b3b8fcef0fa6b61afab540fa78f7cdd3e4d Mon Sep 17 00:00:00 2001 From: Aldy Hernandez Date: Thu, 7 Sep 2023 20:27:35 -0400 Subject: [PATCH] [frange] Revert relation handling in LTGT_EXPR. In trying to come up with a missing testcase for commit 979e0fbf53cd, I've realized the patch doesn't catch anything. A relation of VREL_EQ in foperator_ltgt::fold_range() is either both arguments the same (x LTGT_EXPR x), which we should never emit, or two arguments that are actually the same, in which case !NAN applies, and the whole thing can be handled as NE_EXPR further down. gcc/ChangeLog: * range-op-float.cc (foperator_ltgt::fold_range): Do not special case VREL_EQ nor call frelop_early_resolve. --- gcc/range-op-float.cc | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc index 89c401e040a2..cc729e12a9ec 100644 --- a/gcc/range-op-float.cc +++ b/gcc/range-op-float.cc @@ -2206,21 +2206,6 @@ public: const frange &op1, const frange &op2, relation_trio trio = TRIO_VARYING) const final override { - relation_kind rel = trio.op1_op2 (); - - // VREL_EQ is really VREL_(UN)EQ because we could have a NAN in - // the operands, but since LTGT_EXPR is really a NE_EXPR without - // the NAN, VREL_EQ & LTGT_EXPR is an impossibility. - if (rel == VREL_EQ) - { - r = range_false (type); - return true; - } - // ...otherwise pretend we're trying to resolve a NE_EXPR and - // everything will "just work". - if (frelop_early_resolve (r, type, op1, op2, trio, VREL_NE)) - return true; - if (op1.known_isnan () || op2.known_isnan ()) { r = range_false (type); -- 2.43.5