This reverts r370502, which broke the use case of a copy-only T (with a
deleted move constructor) when exceptions are disabled. Until we figure
out the right behavior, I'm reverting the commit.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@371068 91177308-0d34-0410-b5e6-96231b3b80d8
An upcoming change in Clang will flag _Atomic as being a C11 extension.
To avoid generating this warning in libc++, this commit marks the only
use of _Atomic with the __extension__ extension, which suppresses such
warnings.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@370796 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
`std::vector<T>` is free choose between using copy or move operations when it needs to resize. The standard only candidates that the correct exception safety guarantees are provided. When exceptions are disabled these guarantees are trivially satisfied. Meaning vector is free to optimize it's implementation by moving instead of copying.
This patch makes `std::vector` unconditionally move elements when exceptions are disabled.
This optimization is conforming according to the current standard wording.
There are concerns that moving in `-fno-noexceptions`mode will be a surprise to users. For example, a user may be surprised to find their code is slower with exceptions enabled than it is disabled. I'm sympathetic to this surprised, but I don't think it should block this optimization.
Reviewers: mclow.lists, ldionne, rsmith
Reviewed By: ldionne
Subscribers: zoecarver, christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62228
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@370502 91177308-0d34-0410-b5e6-96231b3b80d8
Since we build the library with -fvisibility=hidden, the shared object
wouldn't contain __vector_base_common<true>::__throw_length_error()
and __vector_base_common<true>::__throw_out_of_range(), leading to
link errors. This only happened on GCC for some reason.
https://llvm.org/PR43140
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@370240 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The resolution of LWG 3199 makes sure that input-streaming into an empty bitset
does not set the failbit on the input stream.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65105
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@369422 91177308-0d34-0410-b5e6-96231b3b80d8
In r292833, we started defining _LIBCPP_CLANG_VER to 0 for Apple Clang.
The result is that AppleClang is detected as being a very old version
of LLVM Clang (version 0), which is obviously incorrect.
I believe this was added so that we don't have to check whether
_LIBCPP_CLANG_VER is defined prior to comparing it with a number
(which can trigger a warning). This commit also fixes the two
places that use the macro correspondingly.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368880 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This avoids symbols being accidentally exported from the dylib when they
shouldn't. The next step is to use a pragma to apply hidden visibility
to all declarations (unless otherwise specified), which will allow us
to drop the per-declaration hidden visibility attributes we currently
have.
This also has the nice side effect of making sure the dylib exports the
same symbols regardless of the optimization level.
PR38138
Reviewers: EricWF, mclow.lists
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D62868
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368703 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
D64914 added support for applying [[nodiscard]] to constructors. This
commit uses that capability to flag incorrect uses of std::lock_guard
where one forgets to actually create a variable for the lock_guard.
rdar://45790820
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits, Quuxplusone, lebedev.ri
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65900
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368664 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We were using implicit deduction guides instead of explicit ones,
however the implicit ones don't do work anymore when changing the
constructors.
This commit adds the actual guides specified in the Standard to make
libc++ (1) closer to the Standard and (2) more resistent to changes
in std::tuple's constructors.
Reviewers: Quuxplusone
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65225
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368599 91177308-0d34-0410-b5e6-96231b3b80d8
This patch rewrites a few loops in deque and split_buffer to better
optimize the codegen. For constructors like
`deque<unsigned char> d(500000, 0);` this patch results in a 2x speedup.
The patch improves the codegen in roughly three ways:
1. Changes do { ... } while (...) loops into more typical for loops.
The optimizer can reason about normal looking loops better.
2. Split the iteration over a range into (A) iteration over the blocks,
then (B) iteration within the block. This nested structure helps LLVM
lower the inner loop to `memset`.
3. Do fewer things each iteration. Some of these loops were incrementing
or changing 4-5 variables every loop (in addition to the
construction). Previously most loops would increment the end pointer,
the size, and decrement the count of remaining items to construct.
Now we only increment a single pointer for most iterations.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368547 91177308-0d34-0410-b5e6-96231b3b80d8
For the few (currently four) headers that make up the PSTL's interface
to other Standard Libraries, provide a stable uglified header file that
can be included by those Standard Libraries.
We can then more easily change the internal organization of the PSTL
without having to change the integration with Standard Libraries.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@368088 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
The first attempt to commit this failed because it exposed a bug in the
tests for modules. Now that this has been fixed, it should be safe to
commit this.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367903 91177308-0d34-0410-b5e6-96231b3b80d8
There are a handful of standard library types that are intended
to support CTAD but don't need any explicit deduction guides to
do so.
This patch adds a dummy deduction guide to those types to suppress
-Wctad-maybe-unsupported (which gets emitted in user code).
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367770 91177308-0d34-0410-b5e6-96231b3b80d8
A previous patch accidentally made the primary template
an incomplete type. This broke some C++03 constructs.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367762 91177308-0d34-0410-b5e6-96231b3b80d8
This patch rewrites a number of old meta-function implementations
that assumed const/volatile could not be safely applied to all types.
This is no longer the case, though for some types (Ex function types),
the const qualifier can be ignored.
The largest improvement in this patch is the reduction of is_function.
Thanks to Matt Calabrese for the improved implementation.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367749 91177308-0d34-0410-b5e6-96231b3b80d8
I have upcoming changes that modify how deque handles spare blocks.
This cleanup is intended to make those changes easier to review
and understand. This patch should have NFC.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367631 91177308-0d34-0410-b5e6-96231b3b80d8
Previously these types rehashed to a table of 193 elements
upon construction. But this is non-ideal, first because default
constructors should not allocate unless necessary, and second
because 193 is big and can waste a bunch of memory.
This number had previously been chosen to match GCC's implementation.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367605 91177308-0d34-0410-b5e6-96231b3b80d8
[cpp.predefined]p2:
__STDCPP_THREADS__
Defined, and has the value integer literal 1, if and only if a program
can have more than one thread of execution .
Also define it only if it's not defined already, since it's supposed
to be defined by the compiler.
Also move it from thread to __config (which requires setting it only
if _LIBCPP_HAS_NO_THREADS is not defined).
Part of PR33230. The intent is to eventually make the compiler define
this instead.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367316 91177308-0d34-0410-b5e6-96231b3b80d8
The optimizer is petulant and temperamental. In this case LLVM failed to lower
the the "insert at end" loop used by`vector<unsigned char>` to a `memset` despite
`memset` being substantially faster over a range of bytes.
LLVM has the ability to lower loops to `memset` whet appropriate, but the
odd nature of libc++'s loops prevented the optimization from taking places.
This patch addresses the issue by rewriting the loops from the form
`do [ ... --__n; } while (__n > 0);` to instead use a for loop over a pointer
range (For example: `for (auto *__i = ...; __i < __e; ++__i)`).
This patch also rewrites the asan annotations to unposion all additional memory
at the start of the loop instead of once per iterations. This could potentially
permit false negatives where the constructor of element N attempts to access
element N + 1 during its construction.
The before and after results for the `BM_ConstructSize/vector_byte/5140480_mean`
benchmark (run 5 times) are:
--------------------------------------------------------------------------------------------
Benchmark Time CPU Iterations
--------------------------------------------------------------------------------------------
Before
------
BM_ConstructSize/vector_byte/5140480_mean 12530140 ns 12469693 ns N/A
BM_ConstructSize/vector_byte/5140480_median 12512818 ns 12445571 ns N/A
BM_ConstructSize/vector_byte/5140480_stddev 106224 ns 107907 ns 5
-----
After
-----
BM_ConstructSize/vector_byte/5140480_mean 167285 ns 166500 ns N/A
BM_ConstructSize/vector_byte/5140480_median 166749 ns 166069 ns N/A
BM_ConstructSize/vector_byte/5140480_stddev 3242 ns 3184 ns 5
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@367183 91177308-0d34-0410-b5e6-96231b3b80d8
The constructors for std::pair and std::tuple have been made conditionally
explicit, however the synopsis in the headers do not reflect that.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366735 91177308-0d34-0410-b5e6-96231b3b80d8
This issue was detected by ASan in one of our tests. This test manually
invokes basic_filebuf::cloe(). fclose(__h.release() returned a non-zero
exit status, so __file_ wasn't set to 0. Later when basic_filebuf
destructor ran, we would enter the if (__file_) block again leading to
heap-use-after-free error.
The POSIX specification for fclose says that independently of the return
value, fclose closes the underlying file descriptor and any further
access (including another call to fclose()) to the stream results in
undefined behavior. This is exactly what happened in our test case.
To avoid this issue, we have to always set __file_ to 0 independently of
the fclose return value.
Differential Revision: https://reviews.llvm.org/D64979
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366730 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts r366593, which caused unforeseen breakage on the build bots.
I'm reverting until the problems have been figured out and fixed.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366603 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This commit allows specifying LIBCXX_ENABLE_PARALLEL_ALGORITHMS when
configuring libc++ in CMake. When that option is enabled, libc++ will
assume that the PSTL can be found somewhere on the CMake module path,
and it will provide the C++17 parallel algorithms based on the PSTL
(that is assumed to be available).
The commit also adds support for running the PSTL tests as part of
the libc++ test suite.
Reviewers: rodgert, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits, mclow.lists, EricWF
Tags: #libc
Differential Revision: https://reviews.llvm.org/D60480
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366593 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This is effectively a revert of r344616, which was a partial fix for
PR38964 (compilation of <string> with GCC in C++03 mode). However, that
configuration is explicitly not supported anymore and that partial fix
breaks compilation with Clang when per-TU insulation is provided.
PR42676
rdar://52899715
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D64941
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366567 91177308-0d34-0410-b5e6-96231b3b80d8
In particular, improve the compile time of the overload set builder
that variant uses to determine which alternative to construct.
Instead of having the __overload type construct itself recursively,
this patch uses a flat construction for the overload set.
git-svn-id: https://llvm.org/svn/llvm-project/libcxx/trunk@366033 91177308-0d34-0410-b5e6-96231b3b80d8
