From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86917 invoked by alias); 22 Jul 2015 17:06:50 -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 86908 invoked by uid 89); 22 Jul 2015 17:06:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham 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; Wed, 22 Jul 2015 17:06:48 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 70DA6BE014; Wed, 22 Jul 2015 17:06:47 +0000 (UTC) Received: from freie.home (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t6MH6jk4009140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jul 2015 13:06:46 -0400 Received: from livre.home (livre.home [172.31.160.2]) by freie.home (8.14.8/8.14.8) with ESMTP id t6MH6Yqd014600; Wed, 22 Jul 2015 14:06:34 -0300 From: Alexandre Oliva To: Richard Biener Cc: Jeff Law , GCC Patches , Christophe Lyon , David Edelsohn , Eric Botcazou Subject: Re: [PR64164] drop copyrename, integrate into expand References: <551A2C7C.8060005@redhat.com> <5522AF73.5000706@redhat.com> Date: Wed, 22 Jul 2015 17:13:00 -0000 In-Reply-To: (Richard Biener's message of "Tue, 21 Jul 2015 15:20:15 +0200") 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-07/txt/msg01876.txt.bz2 On Jul 21, 2015, Richard Biener wrote: > On Sat, Jul 18, 2015 at 9:37 AM, Alexandre Oliva wrote: >> On Jul 16, 2015, Alexandre Oliva wrote: >> + /* If we are assigning parameters for a function, rather >> + than for a call, propagate the RTL of the complex parm to >> + the split declarations, and set their contexts so that >> + maybe_reset_rtl_for_parm can recognize them and refrain >> + from resetting their RTL. */ >> + if (cfun->gimple_df) > If the cfun->gimple_df check is to decide whether this is a call or a function > then no, this can't work reliably. What is this test for else? That was the reason: call or function. > You pass another argument to split_complex_arg, so why not pass in a bool > on whether we split it for this or the other case? There's only one call to split_complex_args. I'll try to figure out where the paths converge and see if it's reasonable to pass an argument all the way to tell the two cases apart. Thanks for the suggestion, -- 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