From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113456 invoked by alias); 5 May 2015 14:34:04 -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 113444 invoked by uid 89); 5 May 2015 14:34:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 05 May 2015 14:34:03 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7EDC92A; Tue, 5 May 2015 07:33:31 -0700 (PDT) Received: from e105689-lin.cambridge.arm.com (e105689-lin.cambridge.arm.com [10.2.207.32]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 116B43F251; Tue, 5 May 2015 07:34:00 -0700 (PDT) Message-ID: <5548D4D6.508@foss.arm.com> Date: Tue, 05 May 2015 14:34:00 -0000 From: Richard Earnshaw User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Jakub Jelinek CC: Richard Biener , gcc-patches@gcc.gnu.org, Martin Jambor , Alan Lawrence Subject: Re: [PATCH] Fix eipa_sra AAPCS issue (PR target/65956) References: <20150505073228.GH1751@tucnak.redhat.com> <5548A174.4010208@foss.arm.com> <5548A327.3080103@foss.arm.com> <5548BBBC.7060000@foss.arm.com> <5548BC73.8030506@foss.arm.com> <20150505125431.GJ1751@tucnak.redhat.com> <5548BF5B.9000904@foss.arm.com> <20150505130650.GK1751@tucnak.redhat.com> <5548C3AB.4050607@foss.arm.com> <20150505142909.GP1751@tucnak.redhat.com> <5548D4A8.4070105@foss.arm.com> In-Reply-To: <5548D4A8.4070105@foss.arm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00338.txt.bz2 On 05/05/15 15:33, Richard Earnshaw wrote: > On 05/05/15 15:29, Jakub Jelinek wrote: >> On Tue, May 05, 2015 at 02:20:43PM +0100, Richard Earnshaw wrote: >>> On 05/05/15 14:06, Jakub Jelinek wrote: >>>> On Tue, May 05, 2015 at 02:02:19PM +0100, Richard Earnshaw wrote: >>>>> In a literal sense, yes. However, even K&R & stdarg have standard >>>>> promotion and conversion rules (size < int => int, floats promoted to >>>>> double, etc). What are those rules for GCC's overaligned types (ie >>>>> where in the docs does it say what happens and how a back-end should >>>>> interpret them)? Shouldn't the mid-end be doing that work so as to >>>> >>>> For the middle-end, the TYPE_ALIGN info on expression types is considered >>>> useless, you can get there anything. There is no conversion rule to what >>>> you get for myalignedint + int, or (myalignedint) int, or (int) >>>> myalignedint, etc. >>>> >>>>> create a consistent view of the values passed into the back-end? It >>>>> seems to me that at present the back-end has to be psychic as to what is >>>>> really happening. >>>> >>>> No, the backend just shouldn't consider TYPE_ALIGN on the scalars, and it >>>> seems only arm ever looks at that. >>>> >>> >>> Nothing in the specification for TARGET_FUNCTION_ARG (or any of the >>> related functions) makes any mention of this... >> >> While this requirement isn't documented, it is clearly common sense or at >> least something any kind of testing would reveal immediately. > > Then clearly no such tests exist in the testsuite :-( > Or, more precisely, no such tests existed in 2008, when the code went in. R. > R. > >> And it is nothing broken recently (except that with the SRA changes it hits >> much more often), looking e.g. at GCC 3.2, I'm seeing that expand_call is on >> that testcase also called with pretty random TYPE_ALIGN on the argument >> types; we didn't have GIMPLE then, so it is nothing that GIMPLE brought in. >> >> Jakub >> >