public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/43872]  New: VLAs are not aligned correctly on ARM
@ 2010-04-23 19:12 mikpe at it dot uu dot se
  2010-04-23 19:14 ` [Bug target/43872] " mikpe at it dot uu dot se
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: mikpe at it dot uu dot se @ 2010-04-23 19:12 UTC (permalink / raw)
  To: gcc-bugs

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


^ permalink raw reply	[flat|nested] 8+ messages in thread
[parent not found: <bug-43872-4@http.gcc.gnu.org/bugzilla/>]
end of thread, other threads:[~2011-09-19  6:21 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-04-23 19:12 [Bug target/43872] New: VLAs are not aligned correctly on ARM mikpe at it dot uu dot se
2010-04-23 19:14 ` [Bug target/43872] " mikpe at it dot uu dot se
2010-04-23 19:15 ` mikpe at it dot uu dot se
2010-04-23 21:31 ` rearnsha at gcc dot gnu dot org
     [not found] <bug-43872-4@http.gcc.gnu.org/bugzilla/>
2011-03-17 14:04 ` cltang at gcc dot gnu.org
2011-04-23  8:36 ` cltang at gcc dot gnu.org
2011-04-23  8:38 ` richard.earnshaw at arm dot com
2011-09-19  8:14 ` jye2 at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).