After checking the libc++abi.dylib shipped in macOS 10.13, I can confirm that it contains the align_val_t variants of operator new and operator delete. However, the libc++abi.dylib shipped on macOS 10.12 does not. Differential Revision: https://reviews.llvm.org/D129198
This reverts commit 4817b7729a1846b709ec02b98bfe11b0125f8e8f. It caused some `^/\n` and had some objection about its readability improvement.
The convention does not add //\n. Having all RUN/CHECK lines separated by //\n
makes editor movement difficult (e.g. { } in Vim).
Aligned allocation is not supported on z/OS. This patch sets -faligned-alloc-unavailable as default in z/OS toolchain. Reviewed By: abhina.sreeskantharajan, hubert.reinterpretcast Differential Revision: https://reviews.llvm.org/D87611
This reverts r358409, which I think broke the bots in compiler-rt. Since I'm having trouble reproducing the failure, I'm reverting this until I can investigate locally. llvm-svn: 358437
Summary: In r350649, I changed aligned allocation from being available starting in macosx10.13 to macosx10.14. However, aligned allocation is indeed available starting with macosx10.13, my investigation had been based on the wrong libc++abi dylib. This means that Clang before the fix will be more stringent when it comes to aligned allocation -- it will not allow it when back-deploying to macosx 10.13, when it would actually be safe to do so. Note that a companion change will be coming to fix the libc++ tests. Reviewers: ahatanak Subscribers: jkorous, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60626 llvm-svn: 358409
Summary: r306722 added diagnostics when aligned allocation is used with deployment targets that do not support it, but the first macosx supporting aligned allocation was incorrectly set to 10.13. In reality, the dylib shipped with macosx10.13 does not support aligned allocation, but the dylib shipped with macosx10.14 does. Reviewers: ahatanak Subscribers: christof, jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56445 llvm-svn: 350649
Libc++ needs to know when aligned allocation is supported by clang, but is otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with alignment arguments. This patch implements the following changes: * The `__cpp_aligned_new` feature test macro to no longer be defined when aligned allocation is otherwise enabled but unavailable. * The Darwin driver no longer passes `-faligned-alloc-unavailable` when the user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`. * Instead of a warning Clang now generates a hard error when an aligned allocation or deallocation function is referenced but unavailable. Patch by Eric Fiselier. Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith Reviewed By: rsmith Subscribers: Quuxplusone, cfe-commits Differential Revision: https://reviews.llvm.org/D45015 llvm-svn: 338934
OS instead of inferring it from SDK / environment The OS version is specified in -target should be used instead of the one in an environment variable / SDK name. rdar://35813850 Differential Revision: https://reviews.llvm.org/D40998 llvm-svn: 321099
a c++17 aligned allocation/deallocation function that is unavailable in the standard library on Apple platforms. The aligned functions are implemented only in the following versions or later versions of the OSes, so clang issues diagnostics if the deployment target being targeted is older than these: macosx: 10.13 ios: 11.0 tvos: 11.0 watchos: 4.0 The diagnostics are issued whenever the aligned functions are selected except when the selected function has a definition in the same file. If there is a user-defined function available somewhere else, option -Wno-aligned-allocation-unavailable can be used to silence the diagnostics. rdar://problem/32664169 Differential Revision: https://reviews.llvm.org/D34574 llvm-svn: 306722