------- 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
