patch from paul eggert to fix -0.0/0.0 confusion that breaks glibc

	* real.h (REAL_VALUES_IDENTICAL): New macro.
	* expr.c (is_zeros_p): Don't consider -0.0 to be all zeros.
	* fold-const.c (operand_equal_p): Don't consider -0.0 to be
	identical to 0.0.
	* tree.c (simple_cst_equal): Don't consider -0.0 to have the
	same tree structure as 0.0.
	* varasm.c (immed_real_const_1): Use new REAL_VALUES_IDENTICAL
	macro instead of doing it by hand.

From-SVN: r16472

gcc/ChangeLog

+1997-11-13  Paul Eggert  <eggert@twinsun.com>
+
+	Fix some confusion with IEEE minus zero.
+
+	* real.h (REAL_VALUES_IDENTICAL): New macro.
+
+	* expr.c (is_zeros_p): Don't consider -0.0 to be all zeros.
+	* fold-const.c (operand_equal_p): Don't consider -0.0 to be
+	identical to 0.0.
+	* tree.c (simple_cst_equal): Don't consider -0.0 to have the
+	same tree structure as 0.0.
+
+	* varasm.c (immed_real_const_1): Use new REAL_VALUES_IDENTICAL
+	macro instead of doing it by hand.
+
 Thu Nov 13 16:56:14 1997  Jeffrey A Law  (law@cygnus.com)
 
 	* v850/lib1funcs.asm: Minor whitespace changes.

gcc/expr.c

@@ -3476,7 +3476,7 @@ is_zeros_p (exp)
 	is_zeros_p (TREE_REALPART (exp)) && is_zeros_p (TREE_IMAGPART (exp));
 
     case REAL_CST:
-      return REAL_VALUES_EQUAL (TREE_REAL_CST (exp), dconst0);
+      return REAL_VALUES_IDENTICAL (TREE_REAL_CST (exp), dconst0);
 
     case CONSTRUCTOR:
       if (TREE_TYPE (exp) && TREE_CODE (TREE_TYPE (exp)) == SET_TYPE)

gcc/fold-const.c

@@ -1796,8 +1796,8 @@ operand_equal_p (arg0, arg1, only_const)
       case REAL_CST:
 	return (! TREE_CONSTANT_OVERFLOW (arg0)
 		&& ! TREE_CONSTANT_OVERFLOW (arg1)
-		&& REAL_VALUES_EQUAL (TREE_REAL_CST (arg0),
-				      TREE_REAL_CST (arg1)));
+		&& REAL_VALUES_IDENTICAL (TREE_REAL_CST (arg0),
+					  TREE_REAL_CST (arg1)));
 
       case COMPLEX_CST:
 	return (operand_equal_p (TREE_REALPART (arg0), TREE_REALPART (arg1),

gcc/real.h

@@ -294,6 +294,13 @@ do { REAL_VALUE_TYPE in = (IN);  /* Make sure it's not in a register.  */\
 #define REAL_VALUE_TO_TARGET_LONG_DOUBLE(a, b) REAL_VALUE_TO_TARGET_DOUBLE (a, b)
 #endif
 
+/* Compare two floating-point objects for bitwise identity.
+   This is not the same as comparing for equality on IEEE hosts:
+   -0.0 equals 0.0 but they are not identical, and conversely
+   two NaNs might be identical but they cannot be equal.  */
+#define REAL_VALUES_IDENTICAL(x, y) \
+  (!bcmp ((char *) &(x), (char *) &(y), sizeof (REAL_VALUE_TYPE)))
+
 /* Compare two floating-point values for equality.  */
 #ifndef REAL_VALUES_EQUAL
 #define REAL_VALUES_EQUAL(x, y) ((x) == (y))

gcc/tree.c

@@ -3840,7 +3840,7 @@ simple_cst_equal (t1, t2)
 	&& TREE_INT_CST_HIGH (t1) == TREE_INT_CST_HIGH (t2);
 
     case REAL_CST:
-      return REAL_VALUES_EQUAL (TREE_REAL_CST (t1), TREE_REAL_CST (t2));
+      return REAL_VALUES_IDENTICAL (TREE_REAL_CST (t1), TREE_REAL_CST (t2));
 
     case STRING_CST:
       return TREE_STRING_LENGTH (t1) == TREE_STRING_LENGTH (t2)

gcc/varasm.c

@@ -2245,8 +2245,7 @@ immed_real_const_1 (d, mode)
 
   /* Detect special cases.  */
 
-  /* Avoid REAL_VALUES_EQUAL here in order to distinguish minus zero.  */
-  if (!bcmp ((char *) &dconst0, (char *) &d, sizeof d))
+  if (REAL_VALUES_IDENTICAL (dconst0, d))
     return CONST0_RTX (mode);
   /* Check for NaN first, because some ports (specifically the i386) do not
      emit correct ieee-fp code by default, and thus will generate a core