Bug 13378

Confirmed (I cannot attach the file because it is over 1000KB.

Is this a regression from 3.3?
If not, let's not mark it with target-milestone 3.4.0.
The gcj verifier has several known bugs, and we aren't likely
to fix them for 3.4.  In fact my plan is to replace this verifier
with the one from libgcj.

Not a regression and it looks like the verification is not going to be fixed for 3.4.

(In reply to comment #0)
> 
> The jar-files which caused the problem:
> http://www.scheinwelt.at/~norbertf/gcj/tests/gcjverifybug_test.tar.gz

I could not download this file - can you please put it back in?

Mainline CVS now has GCJ using a new verifier that should fix
most verifier bugs.

Subject: Re:  gcj compiling from jar files - verification
	error

I put it here:
http://www.scheinwelt.at/~norbertf/files/gcj/other_tests/


On Wed, 2005-03-09 at 10:11, rmathew at gcc dot gnu dot org wrote:
> ------- Additional Comments From rmathew at gcc dot gnu dot org  2005-03-09 09:11 -------
> (In reply to comment #0)
> > 
> > The jar-files which caused the problem:
> > http://www.scheinwelt.at/~norbertf/gcj/tests/gcjverifybug_test.tar.gz
> 
> I could not download this file - can you please put it back in?
> 
> Mainline CVS now has GCJ using a new verifier that should fix
> most verifier bugs.
> 

Thanks.

Now the verification errors are gone, but I'm still not 
able to build the package (with or without -findirect-dispatch):
-------------------------------- 8< -------------------------------- 
~/src/tmp/PR13378/gcjverifybug > make
/home/ranmath/src/gcc/build/gcc/gcj -B/home/ranmath/src/gcc/build/gcc/ -B/home/r
anmath/src/gcc/build/i686-pc-linux-gnu/libjava/ -I/home/ranmath/src/gcc/build/i6
86-pc-linux-gnu/libjava/libgcj-4.1.0.jar -L/home/ranmath/src/gcc/build/i686-pc-l
inux-gnu/libjava/.libs -findirect-dispatch -fCLASSPATH=swt.jar:xerces.jar -c jfa
ce-standalone.jar -o jface_standalone.o
org/eclipse/jface/util/OpenStrategy.java: In class 'org.eclipse.jface.util.OpenS
trategy$1':
org/eclipse/jface/util/OpenStrategy.java: In method 'org.eclipse.jface.util.Open
Strategy$1.handleEvent(org.eclipse.swt.widgets.Event)':
org/eclipse/jface/util/OpenStrategy.java:336: error: expected type 'java.lang.Ru
nnable[]' but stack contains 'java.lang.Object'
org/eclipse/jface/util/OpenStrategy.java:336: error: stack underflow
org/eclipse/jface/util/OpenStrategy$1.java:0: confused by earlier errors, bailin
g out
make: *** [default] Error 1
-------------------------------- 8< --------------------------------

This is failing because the bytecode in this .jar really is broken:

public class Test
{
  public static void main(String[] args) throws Exception
  {
    Class f = Class.forName("org.eclipse.jface.util.OpenStrategy$1");
    System.out.println (f);
  }
}

$ java Test
Exception in thread "main" java.lang.VerifyError: (class:
org/eclipse/jface/util/OpenStrategy$1, method: handleEvent signature:
(Lorg/eclipse/swt/widgets/Event;)V) Register 2 contains wrong type
        at java.lang.Class.forName0(Native Method)
        at java.lang.Class.forName(Class.java:164)
        at Test.main(Test.java:7)

However, its questionable whether gcj should actually report this error with
--indirect-dispatch. The verifier is correctly deferring this type check to
runtime via a type assertion but code in expr.c is still doing its own check
(hangover from the old verifier, I guess). Then again its probably a reasonable
assumption to make that java.lang.Object is never assignment-compatible to
anything else.

Closing as won't fix as the Java front-end has been removed from the trunk.