This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Mauve - the remainder (ieee_real_to_integer)
- From: Mark Wielaard <mark at klomp dot org>
- To: java at gcc dot gnu dot org
- Date: 20 Apr 2002 00:45:37 +0200
- Subject: Re: Mauve - the remainder (ieee_real_to_integer)
- References: <1019080941.7866.133.camel@elsschot>
Hi,
Seeing that Andrew had solved the Double/Float/Long problems (on
powerpc) I tried to attack the remaining three Double/Float failures.
On Thu, 2002-04-18 at 00:02, Mark Wielaard wrote:
>
> FAIL: gnu.testlet.java.lang.Double.DoubleTest: Error: test_intValue
> returned wrong results CYGNUS: Float to int conversions - 1 (number 1)
>
> When compiling to byte-code the following prints zero:
>
> public class DT
> {
> public static void main(String[] args)
> {
> System.out.println((int) 3.4e+32);
> }
> }
>
> The actual buyte-code produced contains the zero. It should print
> 2147483647 (maxint), which it does when compiling from source.
>
> FAIL: gnu.testlet.java.lang.Double.DoubleTest: Error: test_longValue
> returned wrong results CYGNUS: Float to int conversions - 1 (number 1)
>
> Same kind of failure, but now for (long) 3.4e+32. The byte-code contains
> -4294967296 but the result should be 9223372036854775807 (maxlong).
> Compiling from source gives the correct result.
>
> FAIL: gnu.testlet.java.lang.Float.FloatTest: Error: test_intValue
> returned wrong results - 1 (number 1)
>
> Same for (int) 3.4e+32f.
>
> Simple testcase for above failures attached. It succeeds when compiling
> from source, it fails when compiling to byte-code.
The solution to this one seemed to be this simple patch which makes sure
that even when we emit a class file the special
convert_ieee_real_to_integer is used and not just convert_to_integer.
diff -u -r1.44 typeck.c
--- typeck.c 3 Dec 2001 23:09:42 -0000 1.44
+++ typeck.c 19 Apr 2002 22:17:05 -0000
@@ -134,7 +134,6 @@
if (code == INTEGER_TYPE)
{
if (! flag_unsafe_math_optimizations
- && ! flag_emit_class_files
&& TREE_CODE (TREE_TYPE (expr)) == REAL_TYPE
&& TARGET_FLOAT_FORMAT == IEEE_FLOAT_FORMAT)
return fold (convert_ieee_real_to_integer (type, expr));
Sadly this is not the solution since with this patch I get one
regression: FAIL: Primes -O output from bytecode->native test
And although the new test program and the FloatTest produce correct
results the DoubleTest now gives:
gnu/testlet/java/lang/Double/DoubleTest.java: In class
`gnu.testlet.java.lang.Double.DoubleTest':
gnu/testlet/java/lang/Double/DoubleTest.java: In method
`gnu.testlet.java.lang.Double.DoubleTest.test_longValue()':
gnu/testlet/java/lang/Double/DoubleTest.java:310: verification error at
PC=32
gnu/testlet/java/lang/Double/DoubleTest.java:310: invalid argument type
gnu/testlet/java/lang/Double/DoubleTest.java:310: expected type
'boolean' but stack contains 'void'
Ah, well, nice try. And at least we now know were to look. I am going to
sleep. Feel free to surprise me with a real solution when I wake up :)
Good night,
Mark