[llvm-bugs] [Bug 25779] New: [ms] Make fewer assumptions about alignment for declspec(align)

[via llvm-bugs]

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

            Bug ID: 25779
           Summary: [ms] Make fewer assumptions about alignment for
                    declspec(align)
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: nicolasweber at gmx.de
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

__declspec(align) and __attribute__((__aligned__)) have slightly different
semantics: The former tells the compiler "try to align this type when you
allocate memory for it yourself, i.e. for static and automatic variables, and
if you did ensure alignment yourself you're free to exploit this". The latter
tells the compiler "when you see an instance of this type anywhere, no matter
if on stack or heap, you can assume that it will be aligned".

MSDN says "The compiler does not guarantee or attempt to preserve the alignment
attribute of data during a copy or data transform operation. For example,
memcpy
can copy a struct declared with __declspec(align(#)) to any location. Note that
ordinary allocators—for example, malloc, C++ operator new, and the Win32
allocators—return memory that is usually not sufficiently aligned for
__declspec(align(#)) structures or arrays of structures. [...] This type now
has
a 32-byte alignment attribute. This means that all static and automatic
instances start on a 32-byte boundary."


Currently, in clang-cl declspec(align) has the __attribute__((__aligned__))
semantics. We should let it have the semantics described on MSDN instead.

-- 
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/20151208/f5654257/attachment.html>