From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11917 invoked by alias); 12 Sep 2004 08:42:28 -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 11900 invoked by uid 48); 12 Sep 2004 08:42:27 -0000 Date: Sun, 12 Sep 2004 08:42:00 -0000 Message-ID: <20040912084227.11898.qmail@sourceware.org> From: "ebotcazou at gcc dot gnu dot org" To: java-prs@gcc.gnu.org In-Reply-To: <20040901184813.17265.ebotcazou@gcc.gnu.org> References: <20040901184813.17265.ebotcazou@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug java/17265] [3.5 Regression] Libjava doesn't build X-Bugzilla-Reason: CC X-SW-Source: 2004-q3/txt/msg00471.txt.bz2 List-Id: ------- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-09-12 08:42 ------- > ... sounds like ASM_OUTPUT_DEF isn't working correctly with the solaris > assembler. Please try --save-temps and post the .s output. You correctly guessed, it's related to ASM_OUTPUT_DEF and aliases. > My guess is that Solaris needs to be fixed to not define ASM_OUTPUT_DEF if the > assembler doesn't support it. The Solaris assembler does support equates (hey! it is not that primitive :-) but the equated symbol must be defined somewhere in the file. Here we have both .LL_ZN4java4lang5Class23getDeclaredConstructorsEv13 = _ZN4java4lang5Class23getDeclaredConstructorsEv which assembles fine because the second symbol is defined as .global _ZN4java4lang5Class23getDeclaredConstructorsEv .type _ZN4java4lang5Class23getDeclaredConstructorsEv, #function .proc 0110 _ZN4java4lang5Class23getDeclaredConstructorsEv: and .LL_ZN4java4lang5Class17getDeclaringClassEv20 = _ZN4java4lang5Class17getDeclaringClassEv which doesn't because the second symbol is not defined in the file. I can think of two explanations: - the aliased method should have been defined in the assembly file but for some reason it would not have been used, so the compiler decided to not emit it altogether, - the new code in class.c is somehow abusing the notion of "alias" as it attempts to contruct a local alias of an external function. In the first case, the fix could be to defer the call to assemble_alias until after we know that the method will be emitted; in the second case, the fix could be to add yet another target macro and to guard the new code with it. -- What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW Last reconfirmed|2004-09-01 18:59:04 |2004-09-12 08:42:26 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17265