From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27094 invoked by alias); 16 Jul 2002 01:46:03 -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 27061 invoked by uid 71); 16 Jul 2002 01:46:02 -0000 Date: Mon, 15 Jul 2002 18:46:00 -0000 Message-ID: <20020716014602.27059.qmail@sources.redhat.com> To: amodra@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Alan Modra Subject: Re: other/7114: ICE building strcoll.op from glibc-2.2.5 Reply-To: Alan Modra X-SW-Source: 2002-07/txt/msg00475.txt.bz2 List-Id: The following reply was made to PR other/7114; it has been noted by GNATS. From: Alan Modra To: Geoff Keating , d.mueller@elsoft.ch, gcc-gnats@gcc.gnu.org, gcc-patches@gcc.gnu.org, dje@watson.ibm.com Cc: Subject: Re: other/7114: ICE building strcoll.op from glibc-2.2.5 Date: Tue, 16 Jul 2002 11:08:16 +0930 On Tue, Jul 16, 2002 at 09:20:27AM +0930, Alan Modra wrote: > The testcase saves r30 and r31, but both are marked unused (don't > appear in regs_ever_live). Later rtl analysis decides that the > save instruction can be eliminated, thus the ICE. The real bug is > that r30 is not marked used when current_function_needs_context. > This is also the reason for PR5967. > > The code that I copied from the !using_store_multiple case just > papers over this bug. So the above patch merely makes -mmultiple > and -mno-multiple consistently wrong. It gets worse. rs6000/sysv4.h sets PROFILE_BEFORE_PROLOGUE. That means it is completely wrong for first_reg_to_save to decide r30 needs saving when profiling and current_function_needs_context. It's too late to think about saving r30. What really needs to happen is one of a) Don't use PROFILE_BEFORE_PROLOGUE. or b) Save the static chain reg on the stack somewhere before the mcount call. or c) Clobber r30 in a call to a nested function when profiling is enabled. People would probably scream if we went with (a) as special purpose implementations of mcount might make assumptions about the stack. So, anyone want to speak up on the best way to solve this? -- Alan Modra IBM OzLabs - Linux Technology Centre