[libcxx-commits] [PATCH] D138196: [libc++] Use aligned_alloc instead of posix_memalign for C++17

[Alexander Richardson via Phabricator via libcxx-commits]

arichardson added a comment.

In D138196#3944368 <https://reviews.llvm.org/D138196#3944368>, @ldionne wrote:

> `libcxx/language.support/support.dynamic/new_faligned_allocation.pass.cpp` does this in several places:
>
>   ::operator new(1, std::align_val_t(128))
>
> Here, we're allocating an object of size `1` with an alignment of `128`. However, `aligned_alloc` requires the size to be an integral multiple of the alignment: https://en.cppreference.com/w/cpp/memory/c/aligned_alloc. It seems like only the Darwin implementation properly checks for this case.
>
> I couldn't find anything in http://eel.is/c++draft/support.dynamic#new.syn that would place a similar restriction on the `align_val_t` version of `operator new` -- so I think we technically cannot implement it using `aligned_alloc` if we stick to the C Standard. I suspect this may be a good candidate for a LWG issue, since I don't think this was designed on purpose.

Ah I missed that requirement - this is rather unfortunate. It looks like posix_memalign only requires sizeof(void*) alignment, so calling something like `::operator new(1, std::align_val_t(2))` should also fail there?

It sounds to me like we can't use aligned_alloc at all in this case unless we decide to round up `__size` to `__alignment`.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D138196/new/

https://reviews.llvm.org/D138196