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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
