Bug 28663 - [4.2/4.3 regression] gcj fails to binary-compile eclipse's javac
Summary: [4.2/4.3 regression] gcj fails to binary-compile eclipse's javac
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: java (show other bugs)
Version: 4.2.0
: P5 normal
Target Milestone: 4.3.0
Assignee: Andrew Haley
URL:
Keywords:
Depends on: 28067
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-09 14:37 UTC by bero
Modified: 2007-01-09 20:48 UTC (History)
3 users (show)

See Also:
Host: i586-pc-linux-gnu
Target: i586-pc-linux-gnu
Build: i586-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed: 2006-08-29 10:08:28


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description bero 2006-08-09 14:37:29 UTC
gcj -O2 -fomit-frame-pointer -fweb -frename-registers -fPIC -fjni -shared -Wl,-O2,--as-needed,--enable-new-dtags,-soname,libecj.so.3 -o libecj.so.3 ecj.jar
org/eclipse/jdt/internal/compiler/lookup/Scope.java: In class 'org.eclipse.jdt.internal.compiler.lookup.Scope':
org/eclipse/jdt/internal/compiler/lookup/Scope.java: In method 'org.eclipse.jdt.internal.compiler.lookup.Scope.getType(char[])':
org/eclipse/jdt/internal/compiler/lookup/Scope.java:2256: error: verification failed at PC=18: incompatible return type
org/eclipse/jdt/internal/compiler/lookup/Scope.java: In method 'org.eclipse.jdt.internal.compiler.lookup.Scope.getType(char[][],int)':
org/eclipse/jdt/internal/compiler/lookup/Scope.java:2296: error: verification failed at PC=77: incompatible return type
org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java: In class 'org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference':
org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java: In method 'org.eclipse.jdt.internal.compiler.ast.QualifiedTypeReference.getTypeBinding(org.eclipse.jdt.internal.compiler.lookup.Scope)':
org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java:59: error: verification failed at PC=34: incompatible return type


Works as expected in 4.1.1.
Comment 1 bero 2006-08-15 23:02:04 UTC
Some debugging shows this is related to the new jar -- if I use jar from gcc 4.1.x (or just fastjar 0.93 from www.sourceforge.net/projects/fastjar) to generate the ecj.jar file, I can binary-compile it with gcj 4.2 just fine (I also used gcj 4.2 to turn the .java files into .class files in both cases).
Comment 2 bero 2006-08-16 00:01:08 UTC
Forget about the last comment - there was a typo in my "try old gcc version" script that caused reverting to the old jar to revert to the old gcj for .java->.class compilation too (but not for .jar->.so).

On a further look after noticing and fixing the typo, gcj's .java->.class compiler is at fault.

gcj -C 4.1.1 + jar 4.1.1 + gcj 4.2.0 = ok
gcj -C 4.1.1 + jar 4.2.0 + gcj 4.2.0 = ok
gcj -C 4.2.0 + jar 4.2.0 + gcj 4.2.0 = broken
jikes + jar 4.2.0 + gcj 4.2.0 = ok
Comment 3 bero 2006-08-17 14:45:30 UTC
gcj -C miscompiles just org/eclipse/jdt/internal/compiler/lookup/Scope.java and org/eclipse/jdt/internal/compiler/ast/QualifiedTypeReference.java -- I can generate a perfectly working ecj using gcj -C for all files, then rebuilding the .class files for those 2 files with jikes, then using gcj on the results.
Comment 4 Andrew Haley 2006-08-26 17:35:52 UTC
I need a test case.  Please attach the .class of .jar to this PR.
Comment 5 Andrew Haley 2006-08-26 17:37:53 UTC
If you can generate this failure with just the class files, please supply those instead of the whole jar.
Comment 6 Hanno Meyer-Thurow 2006-08-27 12:31:39 UTC
After some testing I can say that this is caused by the fix to bug 27529.
Comment 7 Hanno Meyer-Thurow 2006-08-28 21:45:27 UTC
I stored my broken ecj-3.2.jar here:
http://geki.ath.cx/hacks/ecj.jar
Comment 8 Andrew Haley 2006-08-29 10:08:28 UTC
OK, I'm working on this.  It looks like a regression from 4.1.1 -> 4.1.2.
Comment 9 Andrew Haley 2006-08-29 10:37:02 UTC
OK, here it is:

old:

 14: invokevirtual <Method org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (char[],int)org.eclipse.jdt.internal.compiler.lookup.Binding>
 17: checkcast <Class org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding>
 20: areturn

new:

 14: invokevirtual <Method org.eclipse.jdt.internal.compiler.lookup.Scope.getTypeOrPackage (char[],int)org.eclipse.jdt.internal.compiler.lookup.Binding>
 17: areturn
Comment 10 Andrew Haley 2006-08-29 14:05:28 UTC
class Psupersuper
{
}

class Psuper extends Psupersuper
{
}

class P extends Psuper
{
  Psupersuper barf()
  {
    return new P();
  }
}


class PR28663
{
  static Psuper arse ()
  {
    return (P)new P().barf();
  }
}
Comment 11 Andrew Haley 2006-08-29 15:06:11 UTC
Patch at http://gcc.gnu.org/ml/gcc-patches/2006-08/msg01085.html
Comment 12 Tom Tromey 2006-08-29 17:27:19 UTC
PR 28067 blocks this -- when merging the gcj-eclipse branch to trunk,
we should remove the workaround patch.
Comment 13 Tom Tromey 2007-01-09 20:48:49 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.