[llvm-bugs] [Bug 26662] New: clang: x86: __force_align_arg_pointer__ assumes that stack arguments are aligned

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26662

            Bug ID: 26662
           Summary: clang: x86: __force_align_arg_pointer__ assumes that
                    stack arguments are aligned
           Product: clang
           Version: trunk
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: huw at codeweavers.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

When accessing stack arguments in a function marked with the
__force_align_arg_pointer__ attibute, the generated code assumes that the stack
args are 16-byte aligned.  The point of re-aligning the stack with this
attribute is that the stack may not be so aligned.

This is of importance to Wine, where the caller is win32 code with 4-byte
alignment, yet the code is running on a OS/X / Linux host with 16-byte
alignment.

When the function below is compiled with:
clang -O1 -m32  -fno-stack-protector -c  ~/test.c
(stack protection disabled just to simplify disassembly)

struct sixteen
{
    char b[16];
};

void __attribute__((__force_align_arg_pointer__)) __attribute__((__stdcall__))
test_fn( struct sixteen s )
{
    volatile struct sixteen d = s;
}


We get:
_test_fn:
00000000        pushl   %ebp
00000001        movl    %esp, %ebp
00000003        andl    $-0x10, %esp
00000006        subl    $0x20, %esp
00000009        movaps  0x8(%ebp), %xmm0
0000000d        movaps  %xmm0, (%esp)
00000011        movl    %ebp, %esp
00000013        popl    %ebp
00000014        ret     $0x10

Note that while the stack is successfully re-aligned (andl $-0x10, %esp), the
movaps 0x8(%ebp), %xmm0 assumes that the stack was originally 16-byte aligned.
It should not make that assumption.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20160218/588461bd/attachment.html>