From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8299 invoked by alias); 21 Jan 2004 00:30:51 -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 8279 invoked from network); 21 Jan 2004 00:30:50 -0000 Received: from unknown (HELO main.gmane.org) (80.91.224.249) by sources.redhat.com with SMTP; 21 Jan 2004 00:30:50 -0000 Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aj6Gf-0004cg-00 for ; Wed, 21 Jan 2004 01:30:49 +0100 To: gcc@gcc.gnu.org Received: from sea.gmane.org ([80.91.224.252]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Aj4M5-0003EM-00 for ; Tue, 20 Jan 2004 23:28:17 +0100 Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aj4M5-0006KY-00 for ; Tue, 20 Jan 2004 23:28:17 +0100 From: Jim Wilson Subject: Re: m68k bootstrapping broken Date: Wed, 21 Jan 2004 00:30:00 -0000 Message-ID: <400DAB88.3080805@specifixinc.com> References: <3FFE1E6A.8030304@develer.com> <20040109214753.GA6321@linux-m68k.org> <400069E6.5080301@develer.com> <20040110173359.A3722@redhat.com> <4000EE16.9020907@develer.com> <20040111145603.GA5311@linux-m68k.org> <20040112232206.GA8966@linux-m68k.org> <20040113221343.GB26292@linux-m68k.org> <40072026.2020601@develer.com> <40082F8B.7080003@develer.com> <40088F7B.4060300@develer.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org Cc: gcc-patches@gcc.gnu.org User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 Cc: gcc@gcc.gnu.org X-SW-Source: 2004-01/txt/msg01603.txt.bz2 Andreas Schwab wrote: > I sometimes get bootstrap failures on ia64, and the one and only > difference between stage2 and stage3 is two insns being swapped in a > single object file without any semantic change. Those failures go away > when changing the environment in any way, and because of that I was unable > to debug that yet. There is a known problem with the scheduler's use of cselib. This only happens on IA-64, because only IA-64 uses the sched-ebb.c file which enables use of cselib. The problem is that the scheduler calls cselib, stores data returned from cselib in scheduler data structures, cselib frees the data when it doesn't need it anymore, and then the scheduler dereferences the already-freed data getting garbage. There was a long discussion about this a few months ago, but it didn't come to any resolution. It was either Jakub or Jan that tracked down the problem to the scheduler's use of cselib. I think it was HJ that reported the initial bootstrapping bug. I've never seen this problem on my machine. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1195 invoked by alias); 21 Jan 2004 01:55:19 -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 1188 invoked from network); 21 Jan 2004 01:55:17 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by sources.redhat.com with SMTP; 21 Jan 2004 01:55:17 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.24) id 1Aj7YS-0004Cw-Tv for gcc@gnu.org; Tue, 20 Jan 2004 20:53:16 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1Aj7Zj-0006NV-2P for gcc@gnu.org; Tue, 20 Jan 2004 20:55:06 -0500 Received: from [66.218.85.37] (helo=mta6.wss.scd.yahoo.com) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Aj4MR-00018y-CO for gcc@gnu.org; Tue, 20 Jan 2004 17:28:39 -0500 Received: from specifixinc.com (24.7.123.142) by mta6.wss.scd.yahoo.com (7.0.016) (authenticated as jim@tuliptree.org) id 400D8B02000108E9; Tue, 20 Jan 2004 14:28:18 -0800 Message-ID: <400DAB88.3080805@specifixinc.com> Date: Wed, 21 Jan 2004 01:55:00 -0000 From: Jim Wilson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030716 MIME-Version: 1.0 Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.devel To: Andreas Schwab CC: Richard Zidlicky , Richard Henderson , gcc@gnu.org, gcc-patches@gcc.gnu.org Subject: Re: m68k bootstrapping broken References: <3FFE1E6A.8030304@develer.com> <20040109214753.GA6321@linux-m68k.org> <400069E6.5080301@develer.com> <20040110173359.A3722@redhat.com> <4000EE16.9020907@develer.com> <20040111145603.GA5311@linux-m68k.org> <20040112232206.GA8966@linux-m68k.org> <20040113221343.GB26292@linux-m68k.org> <40072026.2020601@develer.com> <40082F8B.7080003@develer.com> <40088F7B.4060300@develer.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-0.7 required=5.0 tests=EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,RCVD_IN_RFCI, REFERENCES,REPLY_WITH_QUOTES,USER_AGENT_MOZILLA_UA, X_ACCEPT_LANG version=2.55 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) X-SW-Source: 2004-01/txt/msg01611.txt.bz2 Message-ID: <20040121015500.M5-c6fkyUt59HyjOrTGT8pWBdchEc8V4GezDP6UJcCc@z> Andreas Schwab wrote: > I sometimes get bootstrap failures on ia64, and the one and only > difference between stage2 and stage3 is two insns being swapped in a > single object file without any semantic change. Those failures go away > when changing the environment in any way, and because of that I was unable > to debug that yet. There is a known problem with the scheduler's use of cselib. This only happens on IA-64, because only IA-64 uses the sched-ebb.c file which enables use of cselib. The problem is that the scheduler calls cselib, stores data returned from cselib in scheduler data structures, cselib frees the data when it doesn't need it anymore, and then the scheduler dereferences the already-freed data getting garbage. There was a long discussion about this a few months ago, but it didn't come to any resolution. It was either Jakub or Jan that tracked down the problem to the scheduler's use of cselib. I think it was HJ that reported the initial bootstrapping bug. I've never seen this problem on my machine. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com