http://llvm.org/bugs/show_bug.cgi?id=22634
Marshall Clow (home) <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #13 from Marshall Clow (home) <[email protected]> --- 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.
_______________________________________________ LLVMbugs mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
