From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 52701 invoked by alias); 18 Aug 2015 15:48:33 -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 52680 invoked by uid 89); 18 Aug 2015 15:48:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: eu-smtp-delivery-143.mimecast.com Received: from eu-smtp-delivery-143.mimecast.com (HELO eu-smtp-delivery-143.mimecast.com) (146.101.78.143) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Aug 2015 15:48:22 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-17-m_COL_gjQ4yA-gkZl59knA-1; Tue, 18 Aug 2015 16:48:17 +0100 Received: from [10.2.207.50] ([10.1.2.79]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 18 Aug 2015 16:48:17 +0100 Message-ID: <55D353C1.9000308@arm.com> Date: Tue, 18 Aug 2015 16:18:00 -0000 From: Kyrill Tkachov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Alexandre Oliva CC: GCC Patches Subject: Re: [PR64164] drop copyrename, integrate into expand References: <20150723203112.GB27818@gate.crashing.org> <20150810082355.GA31149@arm.com> <55C8BFC3.3030603@redhat.com> In-Reply-To: X-MC-Unique: m_COL_gjQ4yA-gkZl59knA-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01010.txt.bz2 On 17/08/15 03:56, Alexandre Oliva wrote: > On Aug 16, 2015, Andreas Schwab wrote: > >> Alexandre Oliva writes: >>> On Aug 15, 2015, Andreas Schwab wrote: >>> >>>> FAIL: gcc.target/aarch64/target_attr_crypto_ice_1.c (internal compiler= error) >>>> In file included from >>>> /opt/gcc/gcc-20150815/gcc/testsuite/gcc.target/aarch64/target_attr_cry= pto_ice_1.c:4:0: >>> Are you sure this is a regression introduced by my patch? >> Yes, it reintroduces the ICE. > Ugh. I see this testcase was introduced very recently, so presumably it > wasn't present in the tree that James Greenhalgh tested and confirmed > there were no regressions. > > The hack in aarch64-builtins.c looks risky IMHO. Changing the mode of a > decl after RTL is assigned to it (or to its SSA partitions) seems fishy. > The assert is doing just what it was supposed to do. The only surprise > to me is that it didn't catch this unexpected and unsupported change > before. > > Presumably if we just dropped the assert in expand_expr_real_1, this > case would work just fine, although the unsignedp bit would be > meaningless and thus confusing, since the subreg isn't about a > promotion, but about reflecting the mode change that was made from under > us. > > May I suggest that you guys find (or introduce) other means to change > the layout and mode of the decl *before* RTL is assigned to the params? Hmm, if in TARGET_SET_CURRENT_FUNCTION, which is called fairly early on to set up cfun I do the relaying of the param decls then it seems to work. Will do some more testing... > I think this would save us a ton of trouble down the road. Just think > how much trouble you'd get if the different modes had different calling > conventions, alignment requirements, valid register assignments, or > anything that might make coalescing their SSA names with those of other > variables invalid. >