Bug 9861

Summary: method name mangling ignores return type
Product: gcc Reporter: sf
Component: javaAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED FIXED    
Severity: normal CC: aph, gcc-bugs, ian, java-prs, tj
Priority: P3 Keywords: ABI, rejects-valid, wrong-code
Version: 3.2.1   
Target Milestone: 4.2.0   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2005-04-22 05:01:52
Bug Depends on: 12758    
Bug Blocks: 22091    
Attachments: TestGJ.zip

Description sf 2003-02-26 13:36:00 UTC
The following Generic Java code was compiled to the two classes which can be found in the attachment.

// TestGJ.java begins here

class Test<Type> {

  protected Type x () {
    return null;
  }
}

public class TestGJ extends Test<Integer> {

  protected Integer x () {
    return new Integer (1);
  }

  public static void main (final String[] argv) {
    new TestGJ ().x ().intValue ();
  }
}

// TestGJ.java ends here

If you execute "java TestGJ" (adjust CLASSPATH as necessary) the program runs without error (BTW, there is no output).

But compilation of the class files with gcj fails because of a name clash during assembly.

Release:
gcc-3.2.1

Environment:
gentoo linux 1.4
gcc version 3.2.1 20021207 (Gentoo Linux 3.2.1-20021207)
GNU assembler version 2.13.90.0.18 (i586-pc-linux-gnu) using BFD version 2.13.90.0.18 20030121

How-To-Repeat:
If you execute

gcj -classpath /usr/share/gcc-data/i586-pc-linux-gnu/3.2/java/libgcj-3.2.1.jar:. Test.class TestGJ.class 

you should get output similar to

/tmp/cc5J7vu9.s: Assembler messages:
/tmp/cc5J7vu9.s:150: Error: symbol `_ZN6TestGJ1xEv' is already defined
Comment 1 sf 2003-02-26 13:36:00 UTC
Fix:
The mangled name of a method must contain the method's return type, as in the definition of a method descriptor in the Java Virtual Machine Specification.
Comment 2 Andrew Haley 2003-04-11 13:00:04 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Ouch.  I don't see how we can fix this without breaking CNI
    compatibility with C++.
Comment 3 Andrew Pinski 2003-08-19 15:38:14 UTC
This requires an ABI change.
Comment 4 Andrew Haley 2003-12-30 12:48:10 UTC
It certainly does require an ABI change, but as we're changing the ABI anyway I
wouldn't expect a problem.

In any case, the BC-ABI that we're working on at the moment will solve this
problem.  It's CNI that is the stumbling block in this case.

I'm adding 12758 as a dependency.
Comment 5 Ranjit Mathew 2005-05-26 06:08:34 UTC
Some useful tips can be found here:

  http://gcc.gnu.org/ml/java-patches/2005-q2/msg00558.html
Comment 6 Terry Laurenzo 2005-08-15 22:32:35 UTC
I did some work on this.  It's not quite ready for prime-time:
http://tjlaurenzo.blogspot.com/2005/08/adventures-with-java-5-and-gcj.html

I'll try to roll it up into a proper patch and such when I get the suite rebuilt
and tested.  Since its a breaking ABI change, I imagine the primary audience for
this patch in the short term would be people who really need this bug fixed and
are willing to give up compatibility to do it.
Comment 7 Terry Laurenzo 2005-09-23 19:20:00 UTC
I have submitted a patch to fix this bug to the gcc-patches mailing list.  The
URL of the message is: http://gcc.gnu.org/ml/gcc-patches/2005-09/msg01496.html
Comment 8 Ranjit Mathew 2006-05-15 07:04:10 UTC
This was fixed by TJ's patch applied on 2005-12-10.