[Bug libgcj/17021] libgcj verifier resolves classes too eagerly

[thebohemian at gmx dot net]

------- Comment #6 from thebohemian at gmx dot net  2005-10-18 00:18 -------
With the help of Tromey and the team we made an interesting obervation:

class Foo{
     static Object o;

     void method(){
          o = new RemoveClassFile();
     }
}

This is accepted by you-know-which VM but rejected by GIJ (processing putstatic
opcode in verify.cc leads to _Jv_BytecodeVerifier::ref_intersection::compatible
which in turn resolves the RHS).

Now takes this situation:

class Foo{
     static Thread t;

     void method(){
          t = new RemoveClassFileFromClassWhichInheritsFromThread();
     }
}

This is rejected by the 'other' verifier, too if no class file could be found.
The idea seems to be that the assignment test is short-cutted if the LHS is
Object.

Now we have to find and fix every situation where this can happen. Here is a
partial list:
- static assignment
- non-static assignment
- array assignment
- arguments to methods
- return values
- type state merges (only tromey knows what this is ;) )

*Important*:
If you have real world class files where this bug happens please send them to
me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021