Mauve - the remainder

[Mark Wielaard <mark at klomp dot org>]

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
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: DFT.out
Description: Text document