Bug 9861 - method name mangling ignores return type
Summary: method name mangling ignores return type
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 3.2.1
: P3 normal
Target Milestone: 4.2.0
Assignee: Not yet assigned to anyone
Keywords: ABI, rejects-valid, wrong-code
Depends on: 12758
Blocks: 22091
  Show dependency treegraph
Reported: 2003-02-26 13:36 UTC by sf
Modified: 2006-09-13 04:02 UTC (History)
5 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2005-04-22 05:01:52

TestGJ.zip (647 bytes, application/x-zip )
2003-05-21 15:17 UTC, sf

Note You need to log in before you can comment on or make changes to this bug.
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.


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

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
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:

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:

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.