This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Trunk miscompiles libjava
- From: "Boehm, Hans" <hans_boehm at hp dot com>
- To: "'gcc at gcc dot gnu dot org'" <java at gcc dot gnu dot org>, >, "'java at gcc dot gnu dot org'" <java at gcc dot gnu dot org>
- Date: Fri, 17 May 2002 19:30:13 -0700
- Subject: Trunk miscompiles libjava
On Linux/IA64, and probably other platforms, the trunk gcc miscompiles the isWhiteSpace() method in libjava/java/lang/Character. Apparently the bit-wise & in a return is the problem. This is a regression from 3.1. It fails with the current CVS and failed with the one from a few days ago.
Reduced test case (only isWhitespace is miscompiled, the rest is scaffolding):
class mychar {
public static boolean isWhitespace(char ch)
{
int attr = readChar(ch);
return (((1 << attr) & 0x7000) != 0);
}
private static char readChar(char ch) {
if (ch < 128) return (char) 9;
return 9999;
}
public static void main(String[] argv) {
if (isWhitespace('4'))
System.out.println("FAIL 1");
if (isWhitespace('a'))
System.out.println("FAIL 2");
}
}
Offending RTL instruction (partial diff of trunk (-) against 3.1 output (+)):
(insn 57 56 59 (set (reg:DI 359)
- (zero_extend:DI (subreg:QI (reg:SI 355) 0))) -1 (nil)
+ (and:DI (subreg:DI (reg:SI 355) 0)
+ (const_int 1 [0x1]))) -1 (nil)
(nil))
In both 3.1 and the trunk, the code in the return is compiled as a variable right shift of 0x7000. In the 3.1 version, this is anded against 0x1. In the trunk version the and is dropped.
I didn't yet track this down much further, but it fails at -O0, and the initial rtl is already wrong. It works correctly if I compile to a class file and then interpret with gij. Any ideas?
Hans