Bug 8939 - Class files produced by gcj are incompatible with Sun's vm
Summary: Class files produced by gcj are incompatible with Sun's vm
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 3.2
: P3 normal
Target Milestone: 4.3.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 28067
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-14 08:16 UTC by bhun
Modified: 2007-01-09 20:44 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2003-06-10 14:07:39


Attachments
Tar.class (3.84 KB, application/octet-stream)
2003-05-21 15:17 UTC, bhun
Details

Note You need to log in before you can comment on or make changes to this bug.
Description bhun 2002-12-14 08:16:00 UTC
When running apache.tools.ant.Main with classfiles generated with gcj, the following error is thrown:

java.lang.VerifyError: (class: org/apache/tools/ant/taskdefs/Tar, method: execute signature: ()V) Illegal use of nonvirtual function call
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:140)
	at org.apache.tools.ant.Project.init(Project.java:269)
	at org.apache.tools.ant.Main.runBuild(Main.java:582)
	at org.apache.tools.ant.Main.start(Main.java:196)
	at org.apache.tools.ant.Main.main(Main.java:235)

This is the offending piece of code:

try {
  Class taskClass = Class.forName(value);
   addTaskDefinition(key, taskClass);
} catch (NoClassDefFoundError ncdfe) {

The class files without passing optional flags to the gcj compiler (just the -C)

Release:
gcc-3.2

Environment:
Configured with: ../configure --prefix=/usr --libdir=/usr/lib --with-slibdir=/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit --enable-languages=c,c++,ada,f77,objc,java --host=i586-mandrake-linux-gnu --with-system-zlib
Thread model: posix
gcc version 3.2 (Mandrake Linux 9.0 3.2-1mdk)

How-To-Repeat:
compile jakarta-ant 1.5 with gcj. and run it using Sun's vm.
Comment 1 bhun 2002-12-14 08:16:00 UTC
Fix:
Don't run with Sun's vm. :D
Comment 2 Tom Tromey 2002-12-31 01:48:47 UTC
From: Tom Tromey <tromey@redhat.com>
To: bhun@chello.nl
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/8939: Class files produced by gcj are incompatible with Sun's vm
Date: 31 Dec 2002 01:48:47 -0700

 I looked at this PR a bit tonight.
 
 I believe the bytecode in question is this (I think this is the only
 invokespecial that could be considered incorrect):
 
 395: invokespecial #223=<Method org.apache.tools.ant.taskdefs.Tar$TarCompressionMethod.compress (java.io.OutputStream)java.io.OutputStream>
 
 I believe this code in jcf-write.c is at fault:
 
 	    else if (DECL_CONSTRUCTOR_P (f) || CALL_USING_SUPER (exp)
 		|| METHOD_PRIVATE (f))
 	      OP1 (OPCODE_invokespecial);
 
 I don't currently understand why this particular bytecode is
 considered invalid by the JDK.  The method in question is in fact
 private.  Most likely there is a special member class rule here that
 I'm unaware of; more research required.  (Another possibility is that
 I'm on the wrong track here.  It would help if you could send a
 correct Tar.class as compiled by javac...)
 
 Tom

Comment 3 Tom Tromey 2002-12-31 09:12:47 UTC
From: Tom Tromey <tromey@redhat.com>
To: bhun@chello.nl
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: java/8939: Class files produced by gcj are incompatible with Sun's vm
Date: 31 Dec 2002 09:12:47 -0700

 >>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:
 
 Tom> 395: invokespecial #223=<Method org.apache.tools.ant.taskdefs.Tar$TarCompressionMethod.compress (java.io.OutputStream)java.io.OutputStream>
 
 Tom> The method in question is in fact private.  Most likely there is
 Tom> a special member class rule here that I'm unaware of; more
 Tom> research required.
 
 I looked some more.  It turns out that the reason is obvious: the
 method is private in another class.  There is no special rule for a
 member class; we simply can't call this method.
 
 The JDK handles this case by adding an accessor method.  That is what
 we need to do as well.
 
 Tom
Comment 4 Nathanael C. Nerode 2003-06-10 14:07:39 UTC
"It's a bug."

But it's kind of old.  Is it fixed yet?  Tom?
Comment 5 Tom Tromey 2007-01-09 20:44:40 UTC
All gcj front end bugs have been fixed by the gcj-eclipse branch merge.
I'm mass-closing the affected PRs.
If you believe one of these was closed in error, please reopen it
with a note explaining why.
Thanks.