[Bug tree-optimization/52402] New: IPA-SRA creates aligned loads from unaligned memory

[Bug tree-optimization/52402] New: IPA-SRA creates aligned loads from unaligned memory

[rguenth at gcc dot gnu.org]

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

             Bug #: 52402
           Summary: IPA-SRA creates aligned loads from unaligned memory
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rguenth@gcc.gnu.org
                CC: jamborm@gcc.gnu.org
            Target: x86_64-*-*


The following segfaults at -O2

typedef int v4si __attribute__((vector_size(16)));
struct T { v4si i[2]; int j; };

static v4si __attribute__((noinline))
foo (struct T t)
{
  return t.i[0];
}

static struct T *__attribute__((noinline))
init ()
{
  char *p = __builtin_malloc (sizeof (struct T) + 1);
  p++;
  __builtin_memset (p, 1, sizeof (struct T));
  return (struct T *)p;
}

int main()
{
  struct T *p;
  p = init ();
  if (foo (*p)[0] != 0x01010101)
    __builtin_abort ();
  return 0;
}

this is because ipa-prop.c:ipa_modify_call_arguments blindly loads
from *p as if it were properly aligned.

[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-27 15:28:46 UTC ---
err, forgot the packed attribute on the struct.

[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-02-27
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1
      Known to fail|                            |4.6.2, 4.7.0

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-27 15:31:56 UTC ---
I have a patch.  A regression from before IPA SRA was introduced.

[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.7.0
      Known to fail|4.7.0                       |

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-28 09:16:20 UTC ---
Fixed on trunk sofar.

[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-02-28 09:15:54 UTC ---
Author: rguenth
Date: Tue Feb 28 09:15:49 2012
New Revision: 184619

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

    PR tree-optimization/52402
    * ipa-prop.c (ipa_modify_call_arguments): Properly use
    mis-aligned types when creating the accesses at the call site.

    * gcc.dg/torture/pr52402.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr52402.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-prop.c
    trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory

[amylaar at gcc dot gnu.org]

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

Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amylaar at gcc dot gnu.org
      Known to fail|                            |4.8.1, 4.9.0

--- Comment #5 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #4)
> Fixed on trunk sofar.

What I see on epiphany (at O2 and above, enabling SRA) for
gcc.dg/torture/pr52402.c is that the call of foo.isra.0 in main is done
using an aligned type:

Breakpoint 5, epiphany_function_arg (cum_v=..., mode=TImode, type=0xb7c5f960, 
    named=true)
    at /home/amylaar/adapteva/git/sdk/srcw/gcc/config/epiphany/epiphany.c:2177
2177      CUMULATIVE_ARGS cum = *get_cumulative_args (cum_v);
(gdb) call debug_tree(type)
 <vector_type 0xb7c5f960
    type <integer_type 0xb7bed360 int public SI
        size <integer_cst 0xb7bdd104 constant 32>
        unit size <integer_cst 0xb7bdd118 constant 4>
        align 32 symtab 0 alias set 3 canonical type 0xb7bed360 precision 32
min <integer_cst 0xb7bdd2f8 -2147483648> max <integer_cst 0xb7bdd30c
2147483647>
        pointer_to_this <pointer_type 0xb7beda80>>
    TI
    size <integer_cst 0xb7bdd460 type <integer_type 0xb7bed060 bitsizetype>
constant 128>
    unit size <integer_cst 0xb7bdd474 type <integer_type 0xb7bed000 sizetype>
constant 16>
    align 64 symtab 0 alias set 3 canonical type 0xb7c5f960 nunits 4 context
<translation_unit_decl 0xb7bf2e58 D.1323>
    pointer_to_this <pointer_type 0xb7c5fba0>>

but when the callee foo.isra.0 was compiled before, it got allegedly passed
an unaligned type:

Breakpoint 5, epiphany_function_arg (cum_v=..., mode=TImode, type=0xb7c6f300, 
    named=true)
    at /home/amylaar/adapteva/git/sdk/srcw/gcc/config/epiphany/epiphany.c:2177
2177      CUMULATIVE_ARGS cum = *get_cumulative_args (cum_v);
(gdb) call debug_tree(type)
 <vector_type 0xb7c6f300 v4si
    type <integer_type 0xb7bed360 int public SI
        size <integer_cst 0xb7bdd104 constant 32>
        unit size <integer_cst 0xb7bdd118 constant 4>
        align 32 symtab 0 alias set 3 canonical type 0xb7bed360 precision 32
min <integer_cst 0xb7bdd2f8 -2147483648> max <integer_cst 0xb7bdd30c
2147483647>
        pointer_to_this <pointer_type 0xb7beda80>>
    TI
    size <integer_cst 0xb7bdd460 type <integer_type 0xb7bed060 bitsizetype>
constant 128>
    unit size <integer_cst 0xb7bdd474 type <integer_type 0xb7bed000 sizetype>
constant 16>
    align 8 symtab 0 alias set -1 canonical type 0xb7c5f960 nunits 4 context
<translation_unit_decl 0xb7bf2e58 D.1323>>

When passing 64-bit aligned types, the epiphany ABI uses register pair(s)
to enable double load-store, thus in this case where r0 has already been
used, the argument starts at r2; in the less-aligned case, it starts at
r1.  Thus, the callee expects the argument in a different place than where
it has been put by the caller.

[Bug tree-optimization/52402] IPA-SRA creates aligned loads from unaligned memory

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED
      Known to fail|4.8.1, 4.9.0                |

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
So you say that on Epiphany the ABI of the function depends on the actual
argument alignment?  And this alignment is taken from the _argument_, not
the type of the function prototype?

Thus, if you call foo () at one point with an aligned T and at one point
with an unaligned T then ... what?

It seems to me the Epiphany port uses disconnected information at
call-site vs. function prologue.

[this ought to have been a new bugreport instead of hijacking the old one]

Marking the old one as fixed (4.6 is closed now).  Please open a new bug.