From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11226 invoked by alias); 31 Dec 2002 08:56:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 11212 invoked by uid 71); 31 Dec 2002 08:56:01 -0000 Date: Tue, 31 Dec 2002 00:56:00 -0000 Message-ID: <20021231085601.11211.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Tom Tromey Subject: Re: java/8939: Class files produced by gcj are incompatible with Sun's vm Reply-To: Tom Tromey X-SW-Source: 2002-12/txt/msg01457.txt.bz2 List-Id: The following reply was made to PR java/8939; it has been noted by GNATS. From: Tom Tromey To: bhun@chello.nl Cc: gcc-gnats@gcc.gnu.org Subject: Re: java/8939: Class files produced by gcj are incompatible with Sun's vm Date: 31 Dec 2002 01:48:47 -0700 I looked at this PR a bit tonight. I believe the bytecode in question is this (I think this is the only invokespecial that could be considered incorrect): 395: invokespecial #223= I believe this code in jcf-write.c is at fault: else if (DECL_CONSTRUCTOR_P (f) || CALL_USING_SUPER (exp) || METHOD_PRIVATE (f)) OP1 (OPCODE_invokespecial); I don't currently understand why this particular bytecode is considered invalid by the JDK. The method in question is in fact private. Most likely there is a special member class rule here that I'm unaware of; more research required. (Another possibility is that I'm on the wrong track here. It would help if you could send a correct Tar.class as compiled by javac...) Tom