[Bug target/44903] [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-11 15:17 -------
Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c
        execution test

On Sun, 11 Jul 2010, rguenth at gcc dot gnu dot org wrote:

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

Yes, I don't believe that there ever was a general provision to handle
improperly aligned pointer dereferences in expansion.  However, I think
memcpy was special.

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

The test always passed before.  I've attached the .expand file generated using
the 4.5 branch (32-bit) for comparison.

Dave


------- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-11 15:17 -------
Created an attachment (id=21179)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21179&action=view)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44903