HomePhabricator

Distinguish between library and language support for aligned allocation.

Description

Distinguish between library and language support for aligned allocation.

There are two cases:

  1. The library has all it needs to provide align_val_t and the

new/delete overloads needed to support aligned allocation.

  1. The compiler has actually turned the language feature on.

There are times where libc++ needs to distinguish between the two.

This patch adds the additional macro
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION which denotes when case (1)
does not hold. _LIBCPP_HAS_NO_ALIGNED_ALLOCATION is defined whenever
_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION is defined, or when the
compiler has not enabled the language feature.

Additionally this patch cleans up a number of other macros related
to detection of aligned allocation machinery.

Details

Committed
EricWFOct 10 2018, 5:17 PM
Parents
rL344206: [MC][ELF] Fix section_mergeable_size.ll
Branches
Unknown
Tags
Unknown

Event Timeline

ahatanak edited subscribers, added: EricWF, libcxx-commits, ahatanak; removed: hiraditya.Jan 4 2019, 4:17 PM

It seems like this patch causes clang to accept the following code when compiled with -std=c++11. Is this the expected behavior? Shouldn't the compiler reject the code if it's not compiled with -std=c++17 or newer?

$ cat test.cpp

#include <new>

void *p;

int main()
{
  operator delete(p, (std::align_val_t)256);
  return 0;
}

$ clang++ -std=c++11 test.cpp

I'm not sure whether this is something libc++ (as opposed to the compiler) should handle or not. I just wanted to understand what the expected behavior is first.