Mauve - the remainder

Mauve - the remainder

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 3699 bytes --]

Hi,

It seems that the slippage of GCC 3.1 was a positive thing for Mauve
regression test fixing. On i686-pc-linux-gnu there are only 6 unanalyzed
failures left. (And Andrew is chasing the extra failures on powerpc).

Since I don't know how much time I will have till the actual release I
will list the remaining issues. Maybe someone can help analyze and/or
fix them.

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.

FAIL: Compile gnu/testlet/java/lang/Math/min.o for
gnu.testlet.java.lang.Math.min

The verifier doesn't like the byte-code generated by gcj -C:
gnu/testlet/java/lang/Math/min.java: In class
`gnu.testlet.java.lang.Math.min':
gnu/testlet/java/lang/Math/min.java: In method
`gnu.testlet.java.lang.Math.min.test(gnu.testlet.TestHarness)':
gnu/testlet/java/lang/Math/min.java:30: verification error at PC=542
gnu/testlet/java/lang/Math/min.java:30: invalid argument type
gnu/testlet/java/lang/Math/min.java:30: Invalid multi-word value on type
stack

Running from bytecode doesn't work either since the libgcj verifier
finds the same error:
java.lang.VerifyError: verification failed at PC 542 in
gnu.testlet.java.lang.Math.min:test((Lgnu.testlet.TestHarness;)V):
incompatible type on stack

Compiling from source gives the following failures:

FAIL: gnu.testlet.java.lang.Math.min: Float NaNs (number 1)
got 0.0 but expected NaN
FAIL: gnu.testlet.java.lang.Math.min: Float NaNs (number 2)
got 0.0 but expected NaN
2 of 41 tests failed

Interestingly compiling from source with -O2 gives:
gnu/testlet/java/lang/Math/min.java:87: Internal compiler error in
emit_move_insn, at expr.c:2768

But I cannot produce a simple testcase for this even though it seems
that it is triggered by Math.min(2.0f, Float.NaN).

FAIL: gnu.testlet.java.lang.StringBuffer.plus (number 1)

The following program returns false, but should return true:

public class SN
{
        public static void main(String[] args)
        {
                System.out.println("null".equals(n(0) + ""));
        }

        static String n(int i)
        {
                if (i==0) return null; else return "x";
        }
}

The problem is that the String concatenation gets optimized away and
since n(0) returns null it does not generate the string "null" but it
generates the value null. The problem disappears when the return type of
n() is changed to Object.

FAIL: gnu.testlet.java.lang.ref.PhantomReference.phantom: unreachable
(number 1)

Haven't looked at the PhantomReference documentation enough to know what
should happen.

The other thing that should still be done is cleanup the mauve testing
script. At the moment it only works after a make install. And it only
tests source->byte-code->native compilation, not source->native.

Cheers,

Mark

[-- Attachment #2: DFT.java --]
[-- Type: text/x-java, Size: 231 bytes --]

public class DFT
{
	public static void main(String[] args)
	{
		System.out.println((int) 3.4e+32);
		System.out.println((long) 3.4e+32);

		System.out.println((int) 3.4e+32f);
		System.out.println((long) 3.4e+32f);
	}
}

[-- Attachment #3: DFT.out --]
[-- Type: text/plain, Size: 66 bytes --]

2147483647
9223372036854775807
2147483647
9223372036854775807

Re: Mauve - the remainder

[Mark Wielaard]

Hi,

On Thu, 2002-04-18 at 00:02, Mark Wielaard wrote:
> 
> FAIL: gnu.testlet.java.lang.StringBuffer.plus (number 1)
> 
> The following program returns false, but should return true:
> 
> public class SN
> {
>         public static void main(String[] args)
>         {
>                 System.out.println("null".equals(n(0) + ""));
>         }
> 
>         static String n(int i)
>         {
>                 if (i==0) return null; else return "x";
>         }
> }
> 
> The problem is that the String concatenation gets optimized away and
> since n(0) returns null it does not generate the string "null" but it
> generates the value null. The problem disappears when the return type of
> n() is changed to Object.

OK, the following optimization seems to be the problem:

diff -u -r1.353.2.17 parse.y
--- gcc/java/parse.y    15 Apr 2002 09:28:53 -0000      1.353.2.17
+++ gcc/java/parse.y    17 Apr 2002 22:50:38 -0000
@@ -13756,8 +13756,8 @@
     op2 = patch_string_cst (op2);
 
   /* If either one of the constant is null and the other non null
-     operand is a String object, return it. */
-  if (JSTRING_TYPE_P (TREE_TYPE (op1)) && !op2)
+     operand is a String constant, return it. */
+  if ((TREE_CODE (op1) == STRING_CST) && !op2)
     return op1;
 
   /* If OP1 isn't already a StringBuffer, create and

Or does this look to conservative?

Good night,

Mark

Mauve - the remainder

[Andrew Haley]

Mark Wielaard writes:
 > Hi,
 > 
 > It seems that the slippage of GCC 3.1 was a positive thing for Mauve
 > regression test fixing. On i686-pc-linux-gnu there are only 6 unanalyzed
 > failures left. (And Andrew is chasing the extra failures on powerpc).
 > 
 > Since I don't know how much time I will have till the actual release I
 > will list the remaining issues. Maybe someone can help analyze and/or
 > fix them.
 > 
 > 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.

These look like the bugs I'm working on.

Andrew.

Re: Mauve - the remainder (ieee_real_to_integer)

[Mark Wielaard]

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

Re: Mauve - the remainder

[Tom Tromey]

>>>>> "Mark" == Mark Wielaard <mark@klomp.org> writes:

Mark> FAIL: gnu.testlet.java.lang.ref.PhantomReference.phantom: unreachable
Mark> (number 1)

Mark> Haven't looked at the PhantomReference documentation enough to know what
Mark> should happen.

This is almost certainly a buggy test case.  I wrote it, and even at
the time it was a bad idea.  I don't think there is a way to actually
test PhantomReference reliably.

Mark> The other thing that should still be done is cleanup the mauve
Mark> testing script. At the moment it only works after a make
Mark> install. And it only tests source->byte-code->native
Mark> compilation, not source->native.

Thanks.  Please submit (separate) PRs for these, since they are
definitely bugs.

Tom