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: unassignedclangb...@nondot.org
Reporter: nicolaswe...@gmx.de
CC: llvm-bugs@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.
_______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
