This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++: __java_double expressions promote to float


Jason Merrill writes:
 > I told you in person this was OK, but reading over the function again, I
 > see that we don't need to add explicit __java_double support, we just need
 > to stop assuming that any REAL_TYPE not long double or double must be
 > float.  The 'else' should be an 'if' like the others, as specified in the
 > standard.  The default should be to arbitrarily choose one of the two
 > types.  Or perhaps use type_for_mode.

2002-04-10  Andrew Haley  <aph@cambridge.redhat.com>

	* typeck.c (type_after_usual_arithmetic_conversions): 

	When two floating-point operands have the same precision: 
	  convert to float if one of the operands is float;
	  if neither operand is one of the standard types, return the type
	  of the first operand.
 
Index: typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/typeck.c,v
retrieving revision 1.393
diff -c -2 -p -r1.393 typeck.c
*** typeck.c	22 Mar 2002 22:03:04 -0000	1.393
--- typeck.c	10 Apr 2002 14:15:52 -0000
*************** type_after_usual_arithmetic_conversions 
*** 443,449 ****
  	return build_type_attribute_variant (double_type_node,
  					     attributes);
!       else 
  	return build_type_attribute_variant (float_type_node,
  					     attributes);
      }
  }
--- 443,457 ----
  	return build_type_attribute_variant (double_type_node,
  					     attributes);
!       if (same_type_p (TYPE_MAIN_VARIANT (t1), float_type_node)
! 	  || same_type_p (TYPE_MAIN_VARIANT (t2), float_type_node))
  	return build_type_attribute_variant (float_type_node,
  					     attributes);
+       
+       /* Two floating-point types whose TYPE_MAIN_VARIANTs are none of
+          the standard C++ floating-point types.  Logic earlier in this
+          function has already eliminated the possibility that
+          TYPE_PRECISION (t2) != TYPE_PRECISION (t1), so there's no
+          compelling reason to choose one or the other.  */
+       return build_type_attribute_variant (t1, attributes);
      }
  }

 > Also, the function should check for the types actually being the same up
 > where it tests for different precisions; no need to get fancy in that case.

Pardon?

Andrew.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]