[PATCH] D45015: [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.

[Eric Fiselier via Phabricator via cfe-commits]

EricWF added a comment.

In https://reviews.llvm.org/D45015#1119286, @ahatanak wrote:

> In https://reviews.llvm.org/D45015#1105388, @rsmith wrote:
>
> > In https://reviews.llvm.org/D45015#1105372, @vsapsai wrote:
> >
> > > What when compiler has `__builtin_operator_new`, `__builtin_operator_delete`? If I build libc++ tests with recent Clang which has these builtins and run tests with libc++.dylib from old Darwin, there are no linkage errors. Should we define `__cpp_aligned_allocation` in this case?
> >
> >
> > I don't see why that should make any difference -- those builtins call the same functions that the new and delete operator call. Perhaps libc++ isn't calling the forms of those builtins that take an alignment argument yet?
>
>
> It looks like clang currently doesn't issue a warning when a call to __builtin_operator_new or __builtin_operator_delete calls an aligned allocation function that is not support by the OS version. I suppose we should fix this?
>
>   // no warning issued when triple is "thumbv7-apple-ios5.0.0" even though aligned allocation is unavailable.
>   void *p = __builtin_operator_new(100, std::align_val_t(32));


If we switch to no longer defining `__cpp_aligned_new` when it's unavailable that means libc++ shouldn't generate calls to an aligned allocation or deallocation function. Do we need the compiler to protect libc++ from itself here?


Repository:
  rC Clang

https://reviews.llvm.org/D45015