This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
java/1347: Bytecode parser fails on 64-bit systems
- To: java-gnats at sourceware dot cygnus dot com
- Subject: java/1347: Bytecode parser fails on 64-bit systems
- From: jsturm at detroit dot appnet dot com
- Date: 16 Aug 2000 22:30:43 -0000
- Reply-To: jsturm at detroit dot appnet dot com
>Number: 1347
>Category: java
>Synopsis: Bytecode parser fails on 64-bit systems
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: apbianco
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Wed Dec 20 12:19:16 PST 2000
>Closed-Date: Tue Aug 29 09:15:02 PDT 2000
>Last-Modified: Tue Sep 5 18:16:00 PDT 2000
>Originator: Jeff Sturm
>Release: current CVS
>Organization:
>Environment:
alpha-unknown-linux-gnu
>Description:
The bytecode parser doesn't read negative indices correctly
in e.g. tableswitch instructions. It will fail to
compile or dump bytecode with a tableswitch instruction
at a range starting below zero.
>How-To-Repeat:
On a 64-bit machine (alpha, ia64, sparc64) do:
gcj -C Foo.java
jcf-dump Foo.class
You should see something like:
Method name:"foo" public Signature: 6=(int)int
Attribute "Code", length:64, max_stack:3, max_locals:2, code_length:32
0: iload_1
1: tableswitch low=-4294967297, high=1, default=30
-4294967297: 28
-4294967296: 28
-4294967295: 28
Bad byte codes.
>Fix:
Fix WORD_TO_INT to properly sign extend negative numbers on
64-bit architectures. The obvious fix (redefining int32 in
javaop.h to a 32-bit type) fails, so I'm stumped :(
>Release-Note:
>Audit-Trail:
Formerly PR gcj/321
From: Anthony Green <green@cygnus.com>
To: "'java-gnats@sourceware.cygnus.com'"
<java-gnats@sourceware.cygnus.com>,
"'apbianco@cygnus.com'"
<apbianco@cygnus.com>,
"'jsturm@detroit.appnet.com'"
<jsturm@detroit.appnet.com>
Cc:
Subject: re: gcj/321
Date: Wed, 16 Aug 2000 15:59:57 -0700
I noticed the same thing the other day on IA-64. The test_long.java test
case fails because int32 is actually 64-bits on 64-bit hosts.
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view%26pr=321%26database
=java
From: Jeff Sturm <jsturm@detroit.appnet.com>
To: java-gnats@sourceware.cygnus.com, apbianco@cygnus.com
Cc: aph@cygnus.com
Subject: Re: gcj/321
Date: Fri, 18 Aug 2000 17:46:24 -0400
I looked closer at this. The
#define int32 long
is necessary, though it looks wrong, because tree pointers are stored in jword
types (ick). Consequently the WORD_TO_INT macro is wrong:
/* Sign extend w. */
static inline jint
WORD_TO_INT(jword w)
{
jint n = w;
n ^= (jint)1 << 31;
n -= (jint)1 << 31;
return n;
}
I don't really understand the bit arithmetic used there, though it is clearly
intended for 32-bit types. Anyway, the comment is probably wrong... there's no
real "sign extend" taking place since jword and jint are always both the same
size as an int32. A simple cast ought to work, and indeed works for me.
(I'm Cc:'ing Andrew since he originally committed the WORD_TO_INT function.)
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=321&database=java
--
Jeff Sturm
jeff.sturm@appnet.com
From: Jeff Sturm <jsturm@detroit.appnet.com>
To: java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: gcj/321
Date: Sat, 19 Aug 2000 13:16:01 -0400
(This is a resend after my original mail bounced... is java-prs a read-only
list?)
Anthony Green wrote:
> Did you try test_long.java? What was your patch, exactly?
Yes, test_long.java works for me when compiled from either source or bytecode.
This isn't a "patch" really, more like a quick hack... the gcj code as it is
still isn't portable, and probably won't be easy to fix.
In short, since jword and jint must be the same size, the xor and sub statements
negate each other, and WORD_TO_INT becomes nothing but a cast:
Index: javaop.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/javaop.h,v
retrieving revision 1.8
diff -u -p -r1.8 javaop.h
--- javaop.h 2000/05/03 18:09:27 1.8
+++ javaop.h 2000/08/19 15:53:35
@@ -113,10 +113,7 @@ WORD_TO_FLOAT(jword w)
static inline jint
WORD_TO_INT(jword w)
{
- jint n = w;
- n ^= (jint)1 << 31;
- n -= (jint)1 << 31;
- return n;
+ return (jint)w;
}
static inline jlong
From: Jeff Sturm <jsturm@detroit.appnet.com>
To: java-gnats@sourceware.cygnus.com, apbianco@cygnus.com
Cc:
Subject: Re: gcj/321
Date: Fri, 25 Aug 2000 10:11:23 -0400
Andrew posted a patch that should clear up any WORD_TO_INT problems:
http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
Alex, can you close this PR?
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=321&database=java
--
Jeff Sturm
jeff.sturm@appnet.com
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: jeff.sturm@appnet.com, bryce@albatross.co.nz
Cc: java-gnats@sourceware.cygnus.com
Subject: Re: gcj/321
Date: Fri, 25 Aug 2000 08:58:28 -0700 (PDT)
Jeff Sturm writes:
> Andrew posted a patch that should clear up any WORD_TO_INT problems:
>
> http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
Yes. I was also going to give this patch a bit of review and formal
testing before approving it (though I'm pretty sure it's fine.)
> Alex, can you close this PR?
I will. Oh, by the way, have you seen:
http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00907.html
It's the long awaited patch to 252, 214 and 160. Can you please
confirm that it fixes the two PRs you submitted (252 and 214. 214 was
on Alpha hardware.) I'd like Bryce to also confirm that it fixes 160.
If testing goes well, I should be able to check these two patches in
and close 321, 252, 214 and 160. Yeah!
./A
From: Jeff Sturm <jsturm@detroit.appnet.com>
To: apbianco@redhat.com
Cc: bryce@albatross.co.nz, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/321
Date: Fri, 25 Aug 2000 14:00:07 -0400
Alexandre Petit-Bianco wrote:
> Jeff Sturm writes:
> > Andrew posted a patch that should clear up any WORD_TO_INT problems:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
>
> Yes. I was also going to give this patch a bit of review and formal
> testing before approving it (though I'm pretty sure it's fine.)
Oh, that's OK... I meant to say "... if you approve the patch" but hit Send a
little too quick :\
My proposed fix (which you didn't see) typedef'ed jint as an `int' guaranteeing
it would be 32 bits on most (all?) platforms that can host GCC. Andrew left
jint alone, instead fixing WORD_TO_INT to be more tolerant of various integer
widths.
I don't have a strong opinion either way, except that "typedef long int32" is
nonintuitive to say the least... but Andrew's patch indeed fixes gcj/321 on
Alpha (didn't try it on IA32). Also there are too many pointer<->int
conversions in gcj for my comfort.
> > Alex, can you close this PR?
>
> I will. Oh, by the way, have you seen:
>
> http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00907.html
Yes. I haven't looked closely at it... will try it when I get a chance.
Thanks.
--
Jeff Sturm
jeff.sturm@appnet.com
State-Changed-From-To: open->closed
State-Changed-By: apbianco
State-Changed-When: Tue Aug 29 09:15:02 2000
State-Changed-Why:
I just checked in Andrew Haley's patch:
http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
From: apbianco@cygnus.com
To: apbianco@cygnus.com, java-gnats@sourceware.cygnus.com,
jsturm@detroit.appnet.com
Cc:
Subject: Re: gcj/321
Date: 29 Aug 2000 16:15:02 -0000
Synopsis: Bytecode parser fails on 64-bit systems
State-Changed-From-To: open->closed
State-Changed-By: apbianco
State-Changed-When: Tue Aug 29 09:15:02 2000
State-Changed-Why:
I just checked in Andrew Haley's patch:
http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00897.html
http://sources.redhat.com/cgi-bin/gnatsweb.pl?cmd=view&pr=321&database=java
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: jeff.sturm@appnet.com
Cc: bryce@albatross.co.nz, aph@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/321
Date: Tue, 29 Aug 2000 14:44:11 -0700 (PDT)
[I forgot a comma on the CC line.]
Jeff Sturm writes:
> > > Alex, can you close this PR?
> >
> > I will. Oh, by the way, have you seen:
> >
> > http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00907.html
>
> Yes. I haven't looked closely at it... will try it when I get a chance.
> Thanks.
Andrew is confident enough that his patch won't hurt and I haven't
seen regressions that can be tied to it. I'm checking it in because
everyone is seriously itching about having this fixed.
I verified that gcj/252 and 160 are fixed by this patch and I'm going to
close these PRs. I don't handily have access to Alpha hardware -- I'll
let you verify that this patch fixes 252.
./A
From: Jeff Sturm <jeff.sturm@appnet.com>
To: apbianco@redhat.com
Cc: bryce@albatross.co.nz, aph@cygnus.com, java-gnats@sourceware.cygnus.com
Subject: Re: gcj/321
Date: Thu, 31 Aug 2000 15:59:13 -0400
Alexandre Petit-Bianco wrote:
> I verified that gcj/252 and 160 are fixed by this patch and I'm going to
> close these PRs. I don't handily have access to Alpha hardware -- I'll
> let you verify that this patch fixes 252.
It does. Thanks.
--
Jeff Sturm
jeff.sturm@appnet.com
From: Alexandre Petit-Bianco <apbianco@cygnus.com>
To: java-gnats@sourceware.cygnus.com
Cc:
Subject: Re: gcj/321
Date: Tue, 5 Sep 2000 18:12:42 -0700 (PDT)
[It's java-gnats, not java-prs]
Jeff Sturm writes:
> > close these PRs. I don't handily have access to Alpha hardware -- I'll
> > let you verify that this patch fixes 252.
Oops. I meant 214.
> It does. Thanks.
You meant 214?
./A
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="Foo.java"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Foo.java"
cHVibGljIGNsYXNzIEZvbyB7CglwdWJsaWMgaW50IGZvbyhpbnQgbikgewoJCXN3aXRjaCAobikg
ewoJCQljYXNlIC0xOgoJCQljYXNlIDA6CgkJCWNhc2UgMToKCQkJCXJldHVybiAxOwoJCX0KCQly
ZXR1cm4gMDsKCX0KfQo=