From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2377 invoked by alias); 2 Jul 2004 03:58:50 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 2362 invoked from network); 2 Jul 2004 03:58:48 -0000 Received: from unknown (HELO mms1.broadcom.com) (63.70.210.58) by sourceware.org with SMTP; 2 Jul 2004 03:58:48 -0000 Received: from 63.70.210.1 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (MMS v5.6.0)); Thu, 01 Jul 2004 20:58:37 -0700 X-Server-Uuid: 97B92932-364A-4474-92D6-5CFE9C59AD14 Received: from mail-sj1-5.sj.broadcom.com (mail-sj1-5.sj.broadcom.com [10.16.128.236]) by mon-irva-11.broadcom.com (8.9.1/8.9.1) with ESMTP id UAA19869; Thu, 1 Jul 2004 20:58:02 -0700 (PDT) Received: from ldt-sj3-010.sj.broadcom.com (ldt-sj3-010 [10.21.64.10]) by mail-sj1-5.sj.broadcom.com (8.12.9/8.12.9/SSF) with ESMTP id i623waov025390; Thu, 1 Jul 2004 20:58:36 -0700 (PDT) Received: (from cgd@localhost) by ldt-sj3-010.sj.broadcom.com ( 8.11.6/8.9.3) id i623waq06289; Thu, 1 Jul 2004 20:58:36 -0700 X-Authentication-Warning: ldt-sj3-010.sj.broadcom.com: cgd set sender to cgd@broadcom.com using -f To: gcc-bugzilla@gcc.gnu.org cc: gcc-bugs@gcc.gnu.org Subject: Re: [Bug target/16325] value profiling clobbers gp on mips References: <20040702031629.16325.wilson@gcc.gnu.org> <20040702032148.21776.qmail@sourceware.org> From: cgd@broadcom.com Date: Fri, 02 Jul 2004 03:58:00 -0000 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 X-WSS-ID: 6CFA02E72QW15504156-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00121.txt.bz2 List-Id: At Fri, 2 Jul 2004 03:22:10 +0000 (UTC), "wilson at gcc dot gnu dot org" wrote: > This is an inelegant untested patch that makes the testcase work. Cute bug. As for the workaround: o64 will suffer the same problem that o32 does, since it's basically o32 w/ 64-bit GPRs (and therefore, like o32, is required to leave space for a0..a3 on the stack for use by called functions). I don't know if EABI does the same thing. Anyway, I think i'd advise either explicitly checking for o32 or o64, or maybe checking for !TARGET_NEWABI (if EABI does have the same arg space save requirement), instead of checking !TARGET_64BIT. chris