[Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test

[Bug tree-optimization/44903] New: FAIL: gcc.dg/pr35258.c execution test

[danglin at gcc dot gnu dot org]

Wrong code is generated causing bus error in test(gdb):

(gdb) r
Program received signal SIGBUS, Bus error.
0x00002b48 in bar ()
(gdb) disass
Dump of assembler code for function bar:
   0x00002b40 <+0>:     addil L%-800,dp,r1
   0x00002b44 <+4>:     ldo 780(r1),r1
=> 0x00002b48 <+8>:     ldw 1(r1),ret0
   0x00002b4c <+12>:    extrw,u ret0,15,16,r19
   0x00002b50 <+16>:    sth r19,2(r1)
   0x00002b54 <+20>:    sth ret0,4(r1)
   0x00002b58 <+24>:    ldi 2e,ret0
   0x00002b5c <+28>:    bv r0(rp)
   0x00002b60 <+32>:    stb ret0,1(r1)

Register r1 points to str which has 4-byte alignment.  So,
the memory address for the ldw instruction is misaligned.

The test would also fail on linux if the unaligned handler
was disabled.

We have the following for function bar after coalescing:

bar ()
{
  unsigned int D.1980;

  # BLOCK 2 freq:10000
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.1980_3 = MEM[(char * {ref-all})&str + 1B];
  MEM[(char * {ref-all})&str + 2B] = D.1980_3;
  str[1] = 46;
  return;
  # SUCC: EXIT [100.0%] 

}


-- 
           Summary: FAIL: gcc.dg/pr35258.c execution test
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: danglin at gcc dot gnu dot org
 GCC build triplet: hppa*-*-hpux*
  GCC host triplet: hppa*-*-hpux*
GCC target triplet: hppa*-*-hpux*


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

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

[danglin at gcc dot gnu dot org]

------- Comment #1 from danglin at gcc dot gnu dot org  2010-07-10 19:46 -------
Introduced in revision 161655.


-- 

danglin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org
            Summary|FAIL: gcc.dg/pr35258.c      |[4.6 Regression] FAIL:
                   |execution test              |gcc.dg/pr35258.c execution
                   |                            |test


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2010-07-10 21:29 -------
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.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
          Component|tree-optimization           |target
   Target Milestone|---                         |4.6.0


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

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

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-10 23:34 -------
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.

Dave


-- 


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

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

[rguenth at gcc dot gnu dot org]

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

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

[dave at hiauly1 dot hia dot nrc dot ca]

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

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

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2010-07-11 16:23 -------
(In reply to comment #5)
> 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.

In the above case the int type the pointer points to is specified as
being unaligned, so the testcase is valid.

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

The above testcase worked?  Not the pr35258.c, but the one I gave, with
the int aligned(1)?  The difference on the 4.5 branch is that we left the
memcpy call alone and did not inline-expand it on the tree level.

I am trying to say that we hit a latent bug here, and that it's finally time
to fix it (but I don't easily see how to do that in the most efficient way).

> Dave


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-07-11 16:23:49
               date|                            |


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

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

[danglin at gcc dot gnu dot org]

------- Comment #8 from danglin at gcc dot gnu dot org  2010-07-11 16:33 -------
With 4.5, the block move was emitted as follows:

Breakpoint 2, emit_block_move_hints (x=0x7afcb550, y=0x7afcb630, 
    size=0x7af312d8, method=BLOCK_OP_NORMAL, expected_align=64, 
    expected_size=-1) at ../../gcc/gcc/expr.c:1170
1170      rtx retval = 0;
(gdb) bt
#0  emit_block_move_hints (x=0x7afcb550, y=0x7afcb630, size=0x7af312d8, 
    method=BLOCK_OP_NORMAL, expected_align=64, expected_size=-1)
    at ../../gcc/gcc/expr.c:1170
#1  0x002d5e8c in expand_builtin_memcpy (exp=0x7afaae10, target=0x7af312b8)
    at ../../gcc/gcc/builtins.c:3326
#2  0x002dc884 in expand_builtin (exp=0x7afaae10, target=0x7af312b8, 
    subtarget=0x0, mode=VOIDmode, ignore=1) at ../../gcc/gcc/builtins.c:5972
#3  0x004d0cbc in expand_expr_real_1 (exp=0x7afaae10, target=0x0, 
    tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
    at ../../gcc/gcc/expr.c:9262
#4  0x00e043dc in expand_call_stmt (stmt=0x7af299c0)
    at ../../gcc/gcc/cfgexpand.c:1789
#5  0x00e045cc in expand_gimple_stmt_1 (stmt=0x7af299c0)
    at ../../gcc/gcc/cfgexpand.c:1822
#6  0x00e04bfc in expand_gimple_stmt (stmt=0x7af299c0)
    at ../../gcc/gcc/cfgexpand.c:1978
#7  0x00e09348 in expand_gimple_basic_block (bb=0x7afcc240)
    at ../../gcc/gcc/cfgexpand.c:3401
#8  0x00e0ab3c in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:3851
#9  0x0077b644 in execute_one_pass (pass=0x4003c990)
    at ../../gcc/gcc/passes.c:1568
#10 0x0077b928 in execute_pass_list (pass=0x4003c990)
    at ../../gcc/gcc/passes.c:1623
#11 0x016891fc in tree_rest_of_compilation (fndecl=0x7afa4900)
    at ../../gcc/gcc/tree-optimize.c:413
#12 0x00bd40f8 in cgraph_expand_function (node=0x7afb3000)
    at ../../gcc/gcc/cgraphunit.c:1574
#13 0x00bd4460 in cgraph_expand_all_functions ()
    at ../../gcc/gcc/cgraphunit.c:1653
#14 0x00bd4ea4 in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1909
#15 0x00bd2cc4 in cgraph_finalize_compilation_unit ()
    at ../../gcc/gcc/cgraphunit.c:1122
#16 0x000a8524 in c_write_global_declarations ()
    at ../../gcc/gcc/c-decl.c:9519
#17 0x0087a810 in compile_file () at ../../gcc/gcc/toplev.c:1065
#18 0x0087ddb4 in do_compile () at ../../gcc/gcc/toplev.c:2417
#19 0x0087df34 in toplev_main (argc=17, argv=0x7eff05bc)
    at ../../gcc/gcc/toplev.c:2459
#20 0x00252d94 in main (argc=17, argv=0x7eff05bc) at ../../gcc/gcc/main.c:35


-- 


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

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

[dave at hiauly1 dot hia dot nrc dot ca]

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

> The above testcase worked?  Not the pr35258.c, but the one I gave, with
> the int aligned(1)?  The difference on the 4.5 branch is that we left the
> memcpy call alone and did not inline-expand it on the tree level.

The above testcase doesn't work with 4.5 and I doubt it ever worked on
PA.  The pointer passed to foo is used as is.  It's only the memcpy special
case that is handled by 4.5 and earlier.

> I am trying to say that we hit a latent bug here, and that it's finally time
> to fix it (but I don't easily see how to do that in the most efficient way).

Dave


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2010-07-11 22:04 -------
(In reply to comment #9)
> Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
> 
> > The above testcase worked?  Not the pr35258.c, but the one I gave, with
> > the int aligned(1)?  The difference on the 4.5 branch is that we left the
> > memcpy call alone and did not inline-expand it on the tree level.
> 
> The above testcase doesn't work with 4.5 and I doubt it ever worked on
> PA.  The pointer passed to foo is used as is.  It's only the memcpy special
> case that is handled by 4.5 and earlier.

On i?86 we get correct 1-byte alignment for the pointer access while on
my ia64-cross the MEM has 4-byte alignment which is wrong.  t is properly
1-byte aligned (and pointer-to packed structs for example will work only
because there's a handled_component_ref around the pointer dereference).

> > I am trying to say that we hit a latent bug here, and that it's finally time
> > to fix it (but I don't easily see how to do that in the most efficient way).
> 
> Dave
> 


-- 


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

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

[dave at hiauly1 dot hia dot nrc dot ca]

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

> > The above testcase doesn't work with 4.5 and I doubt it ever worked on
> > PA.  The pointer passed to foo is used as is.  It's only the memcpy special
> > case that is handled by 4.5 and earlier.
> 
> On i?86 we get correct 1-byte alignment for the pointer access while on
> my ia64-cross the MEM has 4-byte alignment which is wrong.  t is properly
> 1-byte aligned (and pointer-to packed structs for example will work only
> because there's a handled_component_ref around the pointer dereference).

On hppa64, I see

(insn 7 6 8 3 xxx.c:3 (set (reg:SI 71)
        (mem:SI (reg/v/f:DI 69 [ p ]) [0 *p_1(D)+0 S4 A32])) -1 (nil))

in expand.  The alignment is passed into the move expander.

Dave


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2010-07-11 22:37 -------
(In reply to comment #11)
> Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c execution test
> 
> > > The above testcase doesn't work with 4.5 and I doubt it ever worked on
> > > PA.  The pointer passed to foo is used as is.  It's only the memcpy special
> > > case that is handled by 4.5 and earlier.
> > 
> > On i?86 we get correct 1-byte alignment for the pointer access while on
> > my ia64-cross the MEM has 4-byte alignment which is wrong.  t is properly
> > 1-byte aligned (and pointer-to packed structs for example will work only
> > because there's a handled_component_ref around the pointer dereference).
> 
> On hppa64, I see
> 
> (insn 7 6 8 3 xxx.c:3 (set (reg:SI 71)
>         (mem:SI (reg/v/f:DI 69 [ p ]) [0 *p_1(D)+0 S4 A32])) -1 (nil))
> 
> in expand.  The alignment is passed into the move expander.

For reference, on i?86 I see (on the 4.5 branch):

(insn 6 5 7 3 t.c:3 (set (reg:SI 62)
        (mem:SI (reg/v/f:DI 60 [ p ]) [0 S4 A8])) -1 (nil))

and on trunk:

(insn 6 5 7 3 t.c:3 (set (reg:SI 62)
        (mem:SI (reg/v/f:DI 60 [ p ]) [0 *p_1(D)+0 S4 A8])) -1 (nil))

Richard.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2010-07-13 13:53 -------
Does

Index: expr.c
===================================================================
--- expr.c      (revision 162140)
+++ expr.c      (working copy)
@@ -8778,6 +8778,11 @@ expand_expr_real_1 (tree exp, rtx target
        set_mem_addr_space (temp, as);
        if (TREE_THIS_VOLATILE (exp))
          MEM_VOLATILE_P (temp) = 1;
+       if (STRICT_ALIGNMENT
+           && GET_MODE (temp) != BLKmode
+           && GET_MODE (temp) != VOIDmode
+           && GET_MODE_ALIGNMENT (GET_MODE (temp)) > MEM_ALIGN (temp))
+         PUT_MODE (temp, BLKmode);
        return temp;
       }

make any difference?


-- 


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

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

[mikpe at it dot uu dot se]

------- Comment #14 from mikpe at it dot uu dot se  2010-07-13 17:40 -------
Also fails on sparc64-linux, with SIGBUS due to misaligned load in bar().

On armv5tel-unknown-linux-gnueabi it triggers an alignment exception, which the
Linux kernel may emulate/fixup (there's a kernel tunable for that).


-- 

mikpe at it dot uu dot se changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpe at it dot uu dot se


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

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

[danglin at gcc dot gnu dot org]

------- Comment #15 from danglin at gcc dot gnu dot org  2010-07-14 00:18 -------
We get a segv here:

Program received signal SIGSEGV, Segmentation fault.
0x0017686c in emit_block_move_hints (x=0x7afb3610, y=0x7afb36f0, 
    size=0x7af312d8, method=1074100336, expected_align=0, expected_size=-1)
    at ../../gcc/gcc/expr.c:1146
1146      align = MIN (MEM_ALIGN (x), MEM_ALIGN (y));

(gdb) p debug_rtx (x)
(reg:SI 94 [ D.1980 ])
$2 = void
(gdb) p debug_rtx (y)
(mem/c:BLK (plus:SI (reg/f:SI 97)
        (const_int 1 [0x1])) [0 MEM[(char * {ref-all})&str + 1B]+0 S4 A8])


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2010-07-23 12:14 -------
Mine.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-07-11 16:23:49         |2010-07-23 12:14:22
               date|                            |


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2010-07-26 12:21 -------
One of the issues is

/* For a MEM rtx, the alignment in bits.  We can use the alignment of the
   mode as a default when STRICT_ALIGNMENT, but not if not.  */
#define MEM_ALIGN(RTX)                                                  \
(MEM_ATTRS (RTX) != 0 ? MEM_ATTRS (RTX)->align                          \
 : (STRICT_ALIGNMENT && GET_MODE (RTX) != BLKmode                       \
    ? GET_MODE_ALIGNMENT (GET_MODE (RTX)) : BITS_PER_UNIT))

this might be true during RTL, but certainly during expansion this is wrong.
It invents alignment out of thin air.

Invented by Kenner via

+Tue Oct 23 13:05:53 2001  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
+
...
+       * rtl.h (MEM_ALIGN): Take default from mode, if not BLKmode, and
+       change default if unknown from 1 to BITS_PER_UNIT.

and "fixed up" partly

+Sun Jan 27 13:23:40 2002  Richard Kenner  <kenner@vlsi1.ultra.nyu.edu>
+
+       * emit-rtl.c (get_mem_attrs): Don't default alignment for non-BLKmode
+       if not STRICT_ALIGNMENT.
+       * rtl.h (MEM_ALIGN): Likewise.

which conditionalized it on STRICT_ALIGNMENT.

But store_field still tries to compare MEM_ALIGN for alignment.  This
could have never worked properly.

Thus, for stores I can "fix" it by doing

Index: gcc/emit-rtl.c
===================================================================
--- gcc/emit-rtl.c      (revision 162526)
+++ gcc/emit-rtl.c      (working copy)
@@ -1543,7 +1543,7 @@ set_mem_attributes_minus_bitpos (rtx ref
   tree expr = MEM_EXPR (ref);
   rtx offset = MEM_OFFSET (ref);
   rtx size = MEM_SIZE (ref);
-  unsigned int align = MEM_ALIGN (ref);
+  unsigned int align = MEM_ATTRS (ref) ? MEM_ALIGN (ref) : BITS_PER_UNIT;
   HOST_WIDE_INT apply_bitpos = 0;
   tree type;

Index: gcc/expr.c
===================================================================
--- gcc/expr.c  (revision 162526)
+++ gcc/expr.c  (working copy)
@@ -4168,7 +4168,7 @@ expand_assignment (tree to, tree from, b
      Assignment of an array element at a constant index, and assignment of
      an array element in an unaligned packed structure field, has the same
      problem.  */
-  if (handled_component_p (to)
+  if (1 || handled_component_p (to)
       /* ???  We only need to handle MEM_REF here if the access is not
          a full access of the base object.  */
       || (TREE_CODE (to) == MEM_REF


but unaligned loads are not fixed by that.

Pre-existing mess.  I am not qualified to stir it more.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|rguenth at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2010-07-26 12:45 -------
Created an attachment (id=21314)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21314&action=view)
patch

Please check whether the attached patch fixes the testcase this bug is about.


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2010-07-26 12:45 -------
Mine again (only for restoring the pre-MEM_REF behavior).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2010-07-23 12:14:22         |2010-07-26 12:45:37
               date|                            |


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

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

[dave at hiauly1 dot hia dot nrc dot ca]

------- Comment #20 from dave at hiauly1 dot hia dot nrc dot ca  2010-07-28 00:22 -------
Subject: Re:  [4.6 Regression] FAIL: gcc.dg/pr35258.c
        execution test

On Mon, 26 Jul 2010, rguenth at gcc dot gnu dot org wrote:

> Please check whether the attached patch fixes the testcase this bug is about.

Fixes testcase.  Tested on hppa2.0w-hp-hpux11.11.

Dave


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2010-07-28 10:33 -------
Subject: Bug 44903

Author: rguenth
Date: Wed Jul 28 10:32:54 2010
New Revision: 162624

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162624
Log:
2010-07-28  Richard Guenther  <rguenther@suse.de>

        PR middle-end/44903
        * builtins.c (fold_builtin_memory_op): On STRICT_ALIGNMENT
        targets try harder to not generate unaligned accesses.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c


-- 


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

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

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2010-07-28 10:33 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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