From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16167 invoked by alias); 9 Sep 2003 05:21:36 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 16159 invoked from network); 9 Sep 2003 05:21:35 -0000 Received: from unknown (HELO rwcrmhc13.comcast.net) (204.127.198.39) by sources.redhat.com with SMTP; 9 Sep 2003 05:21:35 -0000 Received: from lucon.org ([12.234.88.5]) by comcast.net (rwcrmhc13) with ESMTP id <2003090905213501500i8p7ve>; Tue, 9 Sep 2003 05:21:35 +0000 Received: by lucon.org (Postfix, from userid 1000) id A88CB2C828; Mon, 8 Sep 2003 22:21:32 -0700 (PDT) Date: Tue, 09 Sep 2003 06:28:00 -0000 From: "H. J. Lu" To: Jan Hubicka Cc: Andreas Schwab , gcc@gcc.gnu.org Subject: Re: Gcc mainline failed to bootstrap on Linux/ia64 Message-ID: <20030909052132.GA4617@lucon.org> References: <20030906230104.GA5623@lucon.org> <20030906231316.GC12333@atrey.karlin.mff.cuni.cz> <20030909000521.GM12333@atrey.karlin.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030909000521.GM12333@atrey.karlin.mff.cuni.cz> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-09/txt/msg00426.txt.bz2 On Tue, Sep 09, 2003 at 02:05:21AM +0200, Jan Hubicka wrote: > > Jan Hubicka writes: > > > > >> Gcc mainline on Sat Sep 6 07:08:21 PDT 2003 failed to bootstrap on > > >> Linux/ia64. I got > > >> > > >> In file included from /net/gnu/export/gnu/src/gcc/gcc/libjava/include/jvm.h:23, > > >> from /net/gnu/export/gnu/src/gcc/gcc/libjava/exception.cc:22: > > >> ./include/java-threads.h:228: internal compiler error: Segmentation fault > > >> Please submit a full bug report, > > >> with preprocessed source if appropriate. > > >> See for instructions. > > > > > > This appears to be related to change of mine to notice_global_symbol. > > > I just commited fix to different problem that may fix it. Can you > > > please ensure that the following patch is in your tree? > > > * cgraph.c (cgraph_mark_reachable_node): Only enqueue finalized functions. > > > (cgraph_varpool_finalize_decl): Notice global symbol when needed. > > > > This is still not fixed. > > > > The problem obviously is that we see global variable placed in register. > I am quite surprised to see this in java, but the attached patch should > help. Can you, please try it out? > Sorry for the delay - bit too many problems to deal with at once :( > > Tue Sep 9 02:03:42 CEST 2003 Jan Hubicka > * varasm.c (notice_global_symbol): Fix dealing with registers. > Index: varasm.c > =================================================================== > RCS file: /cvs/gcc/gcc/gcc/varasm.c,v > retrieving revision 1.381 > diff -c -3 -p -r1.381 varasm.c > *** varasm.c 5 Sep 2003 04:24:26 -0000 1.381 > --- varasm.c 9 Sep 2003 00:03:31 -0000 > *************** notice_global_symbol (tree decl) > *** 1058,1063 **** > --- 1058,1066 ---- > char *name; > rtx decl_rtl = DECL_RTL (decl); > > + if (GET_CODE (decl_rtl) == REG) > + return; > + > p = (* targetm.strip_name_encoding) (XSTR (XEXP (decl_rtl, 0), 0)); > name = xstrdup (p); > I can bootstrap gcc mainline with this patch on Linux/ia64 now. But I got new failures: +FAIL: gcc.c-torture/compile/20000120-2.c (test for excess errors) +FAIL: gcc.c-torture/compile/20011119-1.c (test for excess errors) +FAIL: gcc.c-torture/compile/20011119-1.c (test for excess errors) +FAIL: gcc.c-torture/compile/20011119-1.c (test for excess errors) +FAIL: gcc.c-torture/compile/20011119-1.c (test for excess errors) +FAIL: gcc.c-torture/compile/20011119-2.c (test for excess errors) +FAIL: gcc.c-torture/compile/20011119-2.c (test for excess errors) +FAIL: gcc.c-torture/compile/20011119-2.c (test for excess errors) +FAIL: gcc.c-torture/compile/20011119-2.c (test for excess errors) +FAIL: gcc.dg/debug/20010207-1.c (test for excess errors) +FAIL: gcc.dg/debug/20010207-1.c (test for excess errors) +FAIL: gcc.dg/debug/20010207-1.c (test for excess errors) +FAIL: g++.dg/init/array11.C (test for excess errors) +FAIL: libffi.call/closure_fn0.c output pattern test, is 1 2 3 4 127 429 7 8 0 10 11 97 13 19 21 1 3: 756 +FAIL: libffi.call/closure_fn1.c output pattern test, is 1 2 3 4 127 5 6 8 0 10 11 0 13 19 21 1 3: 234 +FAIL: libffi.call/closure_fn2.c output pattern test, is 1 2 3 4 127 5 6 8 0 10 11 0 13 0 21 1 3: 215 +FAIL: libffi.call/closure_fn3.c output pattern test, is 1 2 3 4 5 6 7 8 9 10 0 0 13 0 0 1 3: 72 +FAIL: libffi.call/cls_1_1byte.c execution test +FAIL: libffi.call/cls_12byte.c execution test +FAIL: libffi.call/cls_16byte.c execution test +FAIL: libffi.call/cls_20byte.c execution test +FAIL: libffi.call/cls_24byte.c execution test +FAIL: libffi.call/cls_2byte.c execution test +FAIL: libffi.call/cls_3_1byte.c execution test +FAIL: libffi.call/cls_3byte1.c execution test +FAIL: libffi.call/cls_3byte2.c execution test +FAIL: libffi.call/cls_4_1byte.c execution test +FAIL: libffi.call/cls_4byte.c execution test +FAIL: libffi.call/cls_5byte.c execution test +FAIL: libffi.call/cls_6byte.c execution test +FAIL: libffi.call/cls_7byte.c execution test +FAIL: libffi.call/cls_8byte.c execution test +FAIL: libffi.call/float2.c execution test +FAIL: libffi.call/float.c execution test +FAIL: libffi.call/nested_struct1.c execution test +FAIL: libffi.call/nested_struct.c execution test +FAIL: libffi.call/problem1.c execution test +FAIL: libffi.call/pyobjc-tc.c execution test +FAIL: libffi.call/struct8.c execution test +FAIL: libffi.special/unwindtest.cc execution test comparing against 20030903. H.J.