From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13026 invoked by alias); 11 Jul 2010 10:47:26 -0000 Received: (qmail 12980 invoked by uid 48); 11 Jul 2010 10:47:12 -0000 Date: Sun, 11 Jul 2010 10:47:00 -0000 Message-ID: <20100711104712.12979.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rguenth at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg01191.txt.bz2 ------- Comment #4 from rguenth at gcc dot gnu dot org 2010-07-11 10:47 ------- (In reply to comment #3) > Subject: Re: [4.6 Regression] FAIL: gcc.dg/pr35258.c > execution test > > On Sat, 10 Jul 2010, rguenth at gcc dot gnu dot org wrote: > > > I get for all memory accesses an alignment of 8 at expansion time which looks > > correct (on i?86). Please debug this a bit, set_mem_attributes_minus_bitpos > > looks conservative enough. > > The rtl in question is the following: > > (insn 8 6 11 /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr35258.c:16 (set (reg:SI > 28 %r28 [orig:94 D.1980 ] [94]) > (mem/c:SI (plus:SI (reg/f:SI 1 %r1 [95]) > (const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str + > 1B]+0 S4 A8])) 37 {*pa.md:2102} (nil)) > > An alignment of 8 is not sufficient for a 4 byte (SImode) load on targets > that define STRICT_ALIGNMENT. We need an alignment of 32. > > I believe the i?86 hardware allows unaligned addresses, so you wouldn't > see the problem. Hm. So the MEM_REF path goes the same way as the INDIRECT_REF path for typedef int t __attribute__((aligned(1),may_alias)); int foo(t *p) { return *p; } int main() { char c[5] = {}; if (foo(&c[1]) != 0) abort (); return 0; } for example on the 4.5 branch. I see no provision to handle not properly aligned pointer dereferences in expansion. So I believe this is a latent issue - but I am quite lost here in the myriads of RTL expansion (which isn't exactly a piece of GCC I am familiar with). In fact with Erics fix for PRxyz (all 32bit sparc tests fail) we now claim an alignment of 32 for the integer load. (CCing Eric - we should factor in the alignemnt of the pointer type as minimum here). But back to the above testcase. On the 4.5 branch I get on i?86: (insn 6 5 7 3 t.c:4 (set (reg:SI 58 [ D.1952 ]) (mem:SI (reg/f:SI 60) [0 S4 A8])) -1 (nil)) (good), but with a cross to ia64-hp-hpux11.23 (I happened to have that around) (insn 7 6 8 3 t.c:4 (set (reg/f:DI 341) (unspec:DI [ (reg:SI 342) ] 24)) -1 (nil)) (insn 8 7 9 3 t.c:4 (set (reg:SI 339 [ D.2007 ]) (mem:SI (reg/f:DI 341) [0 S4 A32])) -1 (nil)) thus an alignment of 32!? A nice way of "fixing" ;) I am curious if the above testcase works for you on the 4.5 branch (or for any version). -- rguenth at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ebotcazou at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903