From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128301 invoked by alias); 31 Mar 2015 11:11:09 -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 128287 invoked by uid 89); 31 Mar 2015 11:11:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx2.suse.de Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Tue, 31 Mar 2015 11:11:08 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 379EEABA2; Tue, 31 Mar 2015 11:11:05 +0000 (UTC) Date: Tue, 31 Mar 2015 11:11:00 -0000 From: Richard Biener To: Jakub Jelinek cc: Alan Lawrence , Richard Earnshaw , Richard Biener , "gcc-patches@gcc.gnu.org" , Marcus Shawcroft Subject: Re: New regression on ARM Linux In-Reply-To: <20150331110750.GE2121@tucnak.redhat.com> Message-ID: References: <55197DAE.1050004@arm.com> <16A8C5AA-994C-4FA3-BC25-8547166DC13C@suse.de> <551A6C46.7010305@foss.arm.com> <551A729F.3090200@foss.arm.com> <551A7B49.7070108@arm.com> <20150331110750.GE2121@tucnak.redhat.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2015-03/txt/msg01641.txt.bz2 On Tue, 31 Mar 2015, Jakub Jelinek wrote: > On Tue, Mar 31, 2015 at 11:47:37AM +0100, Alan Lawrence wrote: > > Richard Biener wrote: > > > > > >But I find it odd that on ARM passing *((aligned_int *)p) as > > >vararg (only as varargs?) changes calling conventions independent > > >of the functions type signature. > > > > Does it? Do you have a testcase, and compilation flags, that'll make this > > show up in an RTL dump? I've tried numerous cases, including AFAICT yours, > > and I always get the value being passed in the expected ("unaligned") > > register? > > If the integral type alignment right now matters, I'd try something like: > > typedef int V __attribute__((aligned (8))); > V x; > > int foo (int x, ...) > { > int z; > __builtin_va_list va; > __builtin_va_start (va, x); > switch (x) > { > case 1: > case 3: > case 6: > z = __builtin_va_arg (va, int); > break; > default: > z = __builtin_va_arg (va, V); > break; > } > __builtin_va_end (va); > return z; > } > > int > bar (void) > { > V v = 3; > int w = 3; > foo (1, (int) v); > foo (2, (V) w); > v = 3; > w = (int) v; > foo (3, w); > foo (4, (V) w); > v = (V) w; > foo (5, v); > foo (6, (int) v); > foo (7, x); > return 0; > } > > (of course, most likely with passing a different value each time and > verification of the result). > As the compiler treats all those casts there as useless, I'd expect > that the types of the passed argument would be pretty much random. > And, note that even on x86_64, the __builtin_va_arg with V expands into > # addr.1_3 = PHI > z_35 = MEM[(V * {ref-all})addr.1_3]; > using exactly the same address for int as well as V va_arg - if you increase > the overalignment arbitrarily, it will surely be a wrong IL because nobody > really guarantees anything about the overalignment. > > So, I think the tree-sra.c patch is a good idea - try to keep using the main > type variants as the types in the IL where possible except for the MEM_REF > first argument (i.e. even the lhs of the load should IMHO not be > overaligned). Yeah, I'm testing it right now as it seems to fix the regression and should be certainly safe. Richard. > As Eric Botcazou said, GCC right now isn't really prepared for under or > overaligned scalars, only when they are in structs (or for middle-end in > *MEM_REFs). > Jakub > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton HRB 21284 (AG Nuernberg)