From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 55786 invoked by alias); 9 Jun 2015 20:12:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 55760 invoked by uid 89); 9 Jun 2015 20:12:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_40,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 09 Jun 2015 20:12:22 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9D1E43173D0; Tue, 9 Jun 2015 20:12:20 +0000 (UTC) Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t59KCBq5028040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jun 2015 16:12:20 -0400 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t59KBkHY001965; Tue, 9 Jun 2015 17:11:47 -0300 From: Alexandre Oliva To: Christophe Lyon Cc: David Edelsohn , GCC Patches , "William J. Schmidt" , Michael Meissner Subject: Re: [PR64164] drop copyrename, integrate into expand References: Date: Tue, 09 Jun 2015 20:24:00 -0000 In-Reply-To: (Alexandre Oliva's message of "Tue, 09 Jun 2015 15:28:41 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2015-06/txt/msg00707.txt.bz2 On Jun 9, 2015, Alexandre Oliva wrote: > On Jun 9, 2015, David Edelsohn wrote: >> This also broke bootstrap on PPC64 LE Linux with the same error. > Thanks for your reports. I'm looking into the problem. > I'd appreciate a preprocessed testcase from either of you to confirm the > fix, if not to help debug it. The first potential source for this problem that jumped at me would be silenced with this change: diff --git a/gcc/function.c b/gcc/function.c index 8bcc352..9201ed9 100644 --- a/gcc/function.c +++ b/gcc/function.c @@ -2974,7 +2974,8 @@ assign_parm_setup_block (struct assign_parm_data_all *all, stack_parm = copy_rtx (stack_parm); if (GET_MODE_SIZE (GET_MODE (entry_parm)) == size) PUT_MODE (stack_parm, GET_MODE (entry_parm)); - set_mem_attributes (stack_parm, parm, 1); + if (GET_CODE (stack_parm) == MEM) + set_mem_attributes (stack_parm, parm, 1); } /* If a BLKmode arrives in registers, copy it to a stack slot. Handle but I suspect there might be other similar issues lurking in function.c after my attempt to turn parm assignment upside down ;-) (namely, it used to assume it could pick stack slots and pseudos in a whim, but after this change it must give way to out-of-SSA's partition assignments.) I'll look into cross-building some embedded targets and see if any further issues surface. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer