[Bug c/57908] New: alignment of arrays allocated stack on amd64/x86_64: 16 bytes ?

[yann at droneaud dot fr]

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

            Bug ID: 57908
           Summary: alignment of arrays allocated stack on amd64/x86_64:
                    16 bytes ?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yann at droneaud dot fr

According to "System V Application Binary Interface, AMD64 Architecture
Processor Supplement, Draft Version 0.90"

    Aggregates and Unions
    ---------------------

    An array uses the same alignment as its elements, except that a local or 
    global array variable that requires at least 16 bytes, or a C99 local or 
    global variable-length array variable, always has alignment of at least 16 
    bytes.[4]
    No other changes required.

    [4] The alignment requirement allows the use of SSE instructions when 
        operating on the array.
        The compiler cannot in general calculate the size of a variable-length 
        array (VLA), but it is expected that most VLAs will require at least 16 
        bytes, so it is logical to mandate that VLAs have at least a 16-byte 
        alignment.


As I understand the ABI specifications, arrays allocated on stack must be
aligned on 16 bytes boundaries, whatever its length is: eg. an array of 7 bytes
get aligned on 16 bytes boundaries.

A test program seems to verify that, with gcc version 4.8.1 20130603 (Red Hat
4.8.1-1) (GCC) :

     kind         name              address   size   alignment   required

   Arrays                                                                
   object |         u8 |     0x7fffefdd486f |    1 |         1 |        1
   object |       u8_0 |     0x7fffefdd4860 |    8 |        32 |        1
   object |       u8_1 |     0x7fffefdd4850 |    7 |        16 |        1
   object |       u8_2 |     0x7fffefdd4840 |    6 |        64 |        1
   object |       u8_3 |     0x7fffefdd4830 |    5 |        16 |        1
   object |       u8_4 |     0x7fffefdd4820 |    4 |        32 |        1
   object |       u8_5 |     0x7fffefdd4810 |    3 |        16 |        1
   object |       u8_6 |     0x7fffefdd4800 |    2 |      2048 |        1
   object |       u8_7 |     0x7fffefdd47ff |    1 |         1 |        1
   object |       u8_8 |     0x7fffefdd47fe |    1 |         2 |        1

IMHO it's a waste of memory and this behavor is inconsistent regarding
structure layout: eg. arrays in structure are not aligned on 16 bytes boundary.

But let's say the specification mandate such stack allocation, aligned on 16
bytes boundary.

Then enter LLVM/Clang clang version 3.3 (tags/RELEASE_33/rc3):

     kind         name              address   size   alignment   required

   Arrays                                                                
   object |         u8 |     0x7fff45f4154f |    1 |         1 |        1
   object |       u8_0 |     0x7fff45f41547 |    8 |         1 |        1
   object |       u8_1 |     0x7fff45f41540 |    7 |        64 |        1
   object |       u8_2 |     0x7fff45f4153a |    6 |         2 |        1
   object |       u8_3 |     0x7fff45f41535 |    5 |         1 |        1
   object |       u8_4 |     0x7fff45f41531 |    4 |         1 |        1
   object |       u8_5 |     0x7fff45f4152e |    3 |         2 |        1
   object |       u8_6 |     0x7fff45f4152c |    2 |         4 |        1
   object |       u8_7 |     0x7fff45f4152b |    1 |         1 |        1
   object |       u8_8 |     0x7fff45f4152a |    1 |         2 |        1

It seems that Clang is not aligning arrays on stack to 16 bytes boundary.

Note: for both compiler, tested on Fedora 19, the results were produced with a
test program compiled with default optimisation flag, with -O3, the results are
quite the same.

The source code of the test is available here:
https://gitorious.org/opteya/alignment/blobs/master/stack-alignment.c