[LLVMbugs] [Bug 22634] operator new and STL containers silently ignore element alignment

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=22634

Marshall Clow (home) <mclow.lists at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #13 from Marshall Clow (home) <mclow.lists at gmail.com> ---
N3396 points out (for a case very similar to yours) that:

    "In this example, not only is an implementation of C++11 not required to
allocate properly-aligned memory, for the array, for practical purposes it is
very nearly required to do the allocation incorrectly; in any event, it is
certainly required to perform the allocation by a process that does not take
the specified alignment value into account".

I'm going to close this as "wontfix", not because I don't think it's a bug - I
think it is - but because it is a problem that the standards group has to
solve. If you disagree and have a solution, please re-open the bug.

When the standard is rectified, clang and libc++ will implement it.

What it boils down to is that by the time you get to operator new, all you've
got is a number of bytes to allocate; all the alignment information has been
discarded. We need a change in the way that operator new works, so as not to
discard that information.

[ Note that *sometimes* clang/libc++ will give you data aligned how you want.
If your memory subsystem hands out addresses at random, and they are all 16
byte aligned, then half of them will be 32-byte aligned. Your test program
handles this by allocating 100 times, and effectively looking for the
least-aligned one in the bunch. ]

P.S. Using gcc 4.9.2 on my mac, I get the same results as clang from your test
program (4, 32, 32, 16, 16, 16)

-- 
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/20150303/2f38262e/attachment.html>