[Bug target/43872] New: VLAs are not aligned correctly on ARM

[Bug target/43872] New: VLAs are not aligned correctly on ARM

[mikpe at it dot uu dot se]

This test case is derived from gcc.c-torture/execute/920929-1.c. It creates a
VLA of doubles and fills it with zeros:

> cat bad-vla-align.c
unsigned long mask = sizeof(double) - 1;

unsigned int __attribute__((noinline)) f(int n)
{
    double v[n];

    while (n > 0)
        v[--n] = 0;

    return (unsigned long)v & mask;
}

int main(void)
{
    if (f(100) != 0)
        __builtin_abort();
    return 0;
}

With -march=armv5te -O2 gcc uses STRD instructions to write 8 bytes at a time.
STRD requires an 8-byte aligned address, but gcc fails to align the VLA to 8
bytes, resulting in misaligned accesses at runtime. Depending on hardware and
kernel configuration, this may result in abnormal termination or slow but
correct execution. On my Marvell Kirkwood machine, it results in EXTREMELY slow
execution due to the high overhead of kernel fixups for alignment traps.

The reason for the misalignment can be seen in the assembly code:

> cat bad-vla-align.s
        .arch armv5te
...
f:
        @ args = 0, pretend = 0, frame = 0
        @ frame_needed = 1, uses_anonymous_args = 0
        @ link register save eliminated.
        str     fp, [sp, #-4]!

sp is 8-byte aligned on entry but not after the prologue.

        mov     r1, r0, asl #3
        add     r3, r1, #8

Both these offsets are multiples of 8.

        add     fp, sp, #0
        cmp     r0, #0
        sub     sp, sp, r3

Now sp == &v[0] is not 8-byte aligned.

        mov     ip, sp
        ble     .L2
        add     r1, sp, r1

r1 == &v[n] is not 8-byte aligned.

        mov     r2, #0
        mov     r3, #0
.L3:
        subs    r0, r0, #1
        strd    r2, [r1, #-8]!

r1 == &v[--n] is not 8-byte aligned so strd fails.
...

I can reproduce this failure with 4.6.0 (r158675) and the 4.5.0 and 4.4.3
releases. 4.3.4 and 4.2.4 appear to work, but I don't know if that is by design
or by accident (different register allocation resulting in different frame
layouts and prologues).

A version of the test case tried to perform the alignment check inside the f
function, but gcc optimized it away completely, apparently "knowing" that the
array address was a multiple of 8. Still another version tried to pass the
array address to a separate checking function, but that changed f's prologue
enough to mask the error.


-- 
           Summary: VLAs are not aligned correctly on ARM
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: mikpe at it dot uu dot se
GCC target triplet: armv5tel-unknown-linux-gnueabi


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

[Bug target/43872] VLAs are not aligned correctly on ARM

[mikpe at it dot uu dot se]

------- Comment #1 from mikpe at it dot uu dot se  2010-04-23 19:14 -------
Created an attachment (id=20476)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20476&action=view)
test case


-- 


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

[Bug target/43872] VLAs are not aligned correctly on ARM

[mikpe at it dot uu dot se]

------- Comment #2 from mikpe at it dot uu dot se  2010-04-23 19:15 -------
Created an attachment (id=20477)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20477&action=view)
gcc-4.6.0 -O2 -march=armv5te -S output


-- 


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

[Bug target/43872] VLAs are not aligned correctly on ARM

[rearnsha at gcc dot gnu dot org]

------- Comment #3 from rearnsha at gcc dot gnu dot org  2010-04-23 21:31 -------
Confirmed on trunk.


-- 

rearnsha at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rearnsha at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-04-23 21:31:24
               date|                            |


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