From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66002 invoked by alias); 31 Mar 2015 10:32:29 -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 65985 invoked by uid 89); 31 Mar 2015 10:32:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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; Tue, 31 Mar 2015 10:32:27 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2VAWMtF027738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 31 Mar 2015 06:32:22 -0400 Received: from tucnak.zalov.cz (ovpn-116-58.ams2.redhat.com [10.36.116.58]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2VAWKY5009285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 31 Mar 2015 06:32:21 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id t2VAWIm0018900; Tue, 31 Mar 2015 12:32:19 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id t2VAWFCF018899; Tue, 31 Mar 2015 12:32:15 +0200 Date: Tue, 31 Mar 2015 10:32:00 -0000 From: Jakub Jelinek To: Richard Earnshaw Cc: Richard Biener , Richard Biener , Alan Lawrence , "gcc-patches@gcc.gnu.org" , Marcus Shawcroft Subject: Re: New regression on ARM Linux Message-ID: <20150331103215.GD2121@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <55193E77.3040401@arm.com> <55193EFB.6030009@arm.com> <55197DAE.1050004@arm.com> <16A8C5AA-994C-4FA3-BC25-8547166DC13C@suse.de> <551A6C46.7010305@foss.arm.com> <551A729F.3090200@foss.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <551A729F.3090200@foss.arm.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01629.txt.bz2 On Tue, Mar 31, 2015 at 11:10:39AM +0100, Richard Earnshaw wrote: > >>> That is, > >>> > >>> typedef int myint __attribute__((aligned(8))); > >>> > >>> int main() > >>> { > >>> myint i = 1; > >>> int j = 2; > >>> __builtin_printf("%d %d\n", i, j); > >>> } > >>> > >>> or > >>> > >>> myint i; > >>> int j; > >>> myint *p = &i; > >>> int *q = &j; > >>> > >>> int main() > >>> { > >>> __builtin_printf("%d %d", *p, *q); > >>> } Note that starting with r221348, gcc fails to profiledbootstrap on armv7hl-linux-gnueabi. I'd hope it is the same thing. To middle-end, all integral type conversions that differ just in alignment are useless - for INTEGRAL_TYPE_P all useless_type_conversion_p cares about is sign and precision. So, if arm has a weirdo ABI that wants to pass aligned types differently (why, I'd say it is just a bug in the ABI), then for named arguments it really has to look at the function type - the type of the argument, rather than the passed in value's type, and for varargs it would be best if it remembered such thing early (in the FEs), because the middle-end can change things any time, with or without Richard B.'s recent SRA change. Jakub