From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24252 invoked by alias); 21 Oct 2005 16:13:44 -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 24223 invoked by uid 48); 21 Oct 2005 16:13:40 -0000 Date: Fri, 21 Oct 2005 16:13:00 -0000 Message-ID: <20051021161340.24222.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/msg00179.txt.bz2 List-Id: ------- Comment #12 from thebohemian at gmx dot net 2005-10-21 16:13 ------- Tromey suggested to not transform all Utf8Const object into a canonical form so I fixed the invokevirtual problem in the first way. I introduced a new method _Jv_equalUt8Const_classnames method which reliably compares classnames of different formats and finds out whether they denote the same Java class. However before I could test the new code I found out that gcj failed to load a certain "[java.lang.String". This was introduced by the new to_array code which assumed that classnames where given in the "Lp1/p2/cn;" format. Unfortunately this is not the case and I had to make that code aware of that fact. I attach the final patch which fixes a) the problems mentioned in this bug b) the problems with array instantiations c) the problem that return type checking always provoked class resolution Please review. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17021