From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19524 invoked by alias); 18 Oct 2005 00:18:29 -0000 Mailing-List: contact java-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-prs-owner@gcc.gnu.org Received: (qmail 19509 invoked by uid 48); 18 Oct 2005 00:18:28 -0000 Date: Tue, 18 Oct 2005 00:18:00 -0000 Message-ID: <20051018001828.19508.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libgcj/17021] libgcj verifier resolves classes too eagerly In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: java-prs@gcc.gnu.org From: "thebohemian at gmx dot net" X-SW-Source: 2005-q4/txt/msg00153.txt.bz2 List-Id: ------- 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