From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20784 invoked by alias); 6 May 2009 15:47:16 -0000 Received: (qmail 20773 invoked by uid 22791); 6 May 2009 15:47:14 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 May 2009 15:46:37 +0000 Received: from cam-owa2.Emea.Arm.com (cam-owa2.emea.arm.com [10.1.105.18]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id n46FkHZm026593; Wed, 6 May 2009 16:46:17 +0100 (BST) Received: from [10.1.129.13] ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 6 May 2009 16:46:32 +0100 Subject: RE: GCC 4.5.0 Status Report (2009-05-05) From: Richard Earnshaw To: Michael Matz Cc: Ramana Radhakrishnan , "'Mark Mitchell'" , gcc@gcc.gnu.org In-Reply-To: References: <20090505162529.2C3D64C1C089@zelda.codesourcery.com> <1241622397.5723.13.camel@pc960.cambridge.arm.com> <4A01A84A.5040200@codesourcery.com> <001101c9ce5f$15affd80$410ff880$@radhakrishnan@arm.com> Content-Type: text/plain Date: Wed, 06 May 2009 15:47:00 -0000 Message-Id: <1241624792.5723.15.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-05/txt/msg00126.txt.bz2 On Wed, 2009-05-06 at 17:44 +0200, Michael Matz wrote: > Hi, > > On Wed, 6 May 2009, Ramana Radhakrishnan wrote: > > > >>> The slush that I requested last week has been lifted. However, I > > >>> have asked for relative calm until the cond-optab branch has been > > >>> merged to mainline, which will hopefully occur on Friday, May 8th. > > >> > > >> As of this morning (UK), native bootstrap on ARM is still broken. > > > > > > Is this PR 39978? > > > > I see what's been reported at > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40031#c2 on gcc55 which appears > > to be the same crash as what Julian's been seeing with > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12. > > As written by Andrew Pinski already, you'll need a different method of > emitting the load of the PIC register. The ARM backend tries to emit that > load as soon as it sees the PIC register being used (which is a slightly > odd method as it magically emits instructions at a place unrelated to the > instruction that currently are supposed to be emitted). > > With expand from SSA this happens earlier than before, in fact so early > that you don't have any basic block in RTL yet. All are still in gimple > form. That's why the emission of RTL insns after the function entry is > not going to work. That's only possible if everything is transformed > already. > > The easiest solution would be to just make a note that you need the PIC > register and then, when expanding the prologue emit the necessary > instructions. IMO that makes sense as PIC register setup usually is > something the prologue does, like all the other register setups necessary. > That won't work because the PIC register on ARM is a pseudo, so generating it during prologue generation is too late. It needs to exist before data flow analysis starts on the RTL. R. -- Richard Earnshaw Email: Richard.Earnshaw@arm.com Engineering Manager Phone: +44 1223 400569 (Direct + VoiceMail) OpenSource Tools Switchboard: +44 1223 400400 ARM Ltd Fax: +44 1223 400410 110 Fulbourn Rd Web: http://www.arm.com/ Cambridge, UK. CB1 9NJ