Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).
This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.
On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.
Reviewers: ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: rsmith, ckennelly, libcxx-commits, christof
Differential Revision: https://reviews.llvm.org/D53120
llvm-svn: 345281
Summary:
When building with -fvisibility=hidden, some symbols do not get exported from
libc++.dylib. This means that some entities are not explicitly given default
visibility in the source code, and that we rely on the fact -fvisibility=default
is the default. This commit explicitly gives default visibility to those
symbols to avoid being dependent on the command line flags used.
The commit also remove symbols from the dylib -- those symbols do not
actually need to be exported from the dylib and this should not be an
ABI break.
Finally, in the future, we may want to mark the whole std:: namespace as
having hidden visibility (to switch from opt-out to opt-in), in which
case the changes done in this commit will be required.
Reviewers: EricWF
Subscribers: mgorny, christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52662
llvm-svn: 345260
Summary:
C++14 sized deallocation is disabled by default due to ABI concerns. However, when a user manually enables it then libc++ should take advantage of it since sized deallocation can provide a significant performance win depending on the underlying malloc implementation. (Note that libc++'s definitions of sized delete don't do anything special yet, but users are free to provide their own).
This patch updates __libcpp_deallocate to selectively call sized operator delete when it's available. `__libcpp_deallocate_unsized` should be used when the size of the allocation is unknown.
On Apple this patch makes no attempt to determine if the sized operator delete is unavailable, only that the language feature is enabled. This could cause a compile error when using `std::allocator`, but the same compile error would occur whenever the user calls `new`, so I don't think it's a problem.
Reviewers: ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: rsmith, ckennelly, libcxx-commits, christof
Differential Revision: https://reviews.llvm.org/D53120
llvm-svn: 345214
This reverts commits r333103 and r333108. _Float16 and __fp16 are C11
extensions and compilers other than Clang don't define these for C++.
Differential Revision: https://reviews.llvm.org/D53670
llvm-svn: 345199
Summary:
Some tests (mainly the new C++20 calendar library) fail when libc++ is
tested with '--param=std=c++98'. The failures happen because the tests
actually don't support C++98, but don't mention C++98 in the
'UNSUPPORTED:' line.
This change fixes the issue.
Reviewers: mclow.lists, ldionne
Reviewed By: ldionne
Subscribers: arphaman, michaelplatings, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53640
llvm-svn: 345148
Summary:
Benchmarks for construct, find, insert and iterate, with sequential
and random ordered inputs.
It also improves the cartesian product benchmark header to allow for
runtime values to be specified in the product.
Reviewers: EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53523
llvm-svn: 345035
The test is trying to avoid saying aligned_alloc on Windows' UCRT, which does not (and can not) implement aligned_alloc. However, it's testing for c1xx, meaning clang on Windows will fail this test when using the UCRT.
llvm-svn: 344829
In this example, the ctor of G runs in the main thread in the expression G(), and also in the copy ctor of G() in the DECAY_COPY inside std::thread. The main thread destroys the G() instance at the semicolon, and the started thread destroys the G() after it returns. Thus there is a race between the threads on the n_alive variable.
The fix is to join with the background thread before attempting to destroy the G in the main thread.
llvm-svn: 344820
Summary:
Running the test suite with -a will now properly show all the executed
commands. The reports also include the environment under which the test
is being executed, which is helpful for reproducing issues.
Reviewers: EricWF
Subscribers: christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53215
llvm-svn: 344700
That macro has been defined to _LIBCPP_HIDE_FROM_ABI_AFTER_V1 for many
weeks now, so we're actually replacing uses of it for uses of
_LIBCPP_HIDE_FROM_ABI_AFTER_V1 directly.
This should not change or break anything since the two macros are
100% equivalent, unless somebody is (incorrectly!) relying on
_LIBCPP_EXTERN_TEMPLATE_INLINE_VISIBILITY being defined.
llvm-svn: 344641
Revert r344535 "Wrap up the new chrono literals in an #ifdef..."
Revert r344546 "Mark a couple of test cases as 'C++17-only'..."
Some of the buildbot failures were masked by another error,
and this one was probably missed.
llvm-svn: 344580
libc++ has dropped support for Mac OS 10.6 for a while, and we don't
have any testers set up for that OS.
This commit puts in an error message so that people can reach out to
the libc++ maintainers in case support for 10.6 is still expected (as
opposed to silently failing in weird ways). We can completely drop
support for 10.6 and remove the error message some time in the future
when we're sure that nobody is relying on it.
llvm-svn: 344576
Summary:
Benchmarks for construct, copy, move, swap, destroy and invoke, with 8
different input states.
For the cases that matter, it tests with and without allowing constant
value propagation from construction into the operation tested.
This also adds helper functions to generate the cartesian product of
different configurations and generate benchmarks for all of them.
Reviewers: EricWF
Subscribers: christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53087
llvm-svn: 344415
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.
2. 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.
llvm-svn: 344207
While __cplusplus was only used a few dozen times, TEST_STD_VAR is used
more than 2000 times. So we replace the former by the latter for
consistency in the tests. There should be no functional change.
llvm-svn: 344194
Eric Fiselier