[gcc r14-3814] [frange] Revert relation handling in LTGT_EXPR.

[gcc r14-3814] [frange] Revert relation handling in LTGT_EXPR.

[Aldy Hernandez]

https://gcc.gnu.org/g:67761b3b8fcef0fa6b61afab540fa78f7cdd3e4d

commit r14-3814-g67761b3b8fcef0fa6b61afab540fa78f7cdd3e4d
Author: Aldy Hernandez <aldyh@redhat.com>
Date:   Thu Sep 7 20:27:35 2023 -0400

    [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.

Diff:
---
 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);