From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113166 invoked by alias); 5 May 2015 13:20:59 -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 113154 invoked by uid 89); 5 May 2015 13:20:57 -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 13:20:52 +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 8804429; Tue, 5 May 2015 06:20:20 -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 A18C93F212; Tue, 5 May 2015 06:20:49 -0700 (PDT) Message-ID: <5548C3AB.4050607@foss.arm.com> Date: Tue, 05 May 2015 13:20: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: <20150504150011.GD1751@tucnak.redhat.com> <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> In-Reply-To: <20150505130650.GK1751@tucnak.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00330.txt.bz2 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... R. > Jakub >