On Fuchsia, pthread API is emulated on top of C11 thread API. Using C11
thread API directly is more efficient.
While this implementation is only used by Fuchsia at the moment, it's
not Fuchsia specific, and could be used by other platforms that use C11
threads rather than pthreads in the future.
Differential Revision: https://reviews.llvm.org/D64378
This also makes this function consistent with the rest of the
libc++ provided fallbacks.
The locale support in msvcrt.dll is very limited anyway; it can
only be configured processwide, not per thread, and it only seems
to support the locales "C" and "" (the user set locale), so it's
hard to make any meaningful automatic test for it. But manually tested,
this change does make time formatting locale code in libc++ output
times in the user requested format, when using locale "".
Differential Revision: https://reviews.llvm.org/D69554
The external instantiation of std::string is a problem for libc++.
Additions and removals of inline functions in string can cause ABI
breakages, including introducing new symbols.
This patch aims to:
(1) Make clear which functions are explicitly instatiated.
(2) Prevent new functions from being accidentally instantiated.
(3) Allow a migration path for adding or removing functions from the
explicit instantiation over time.
Although this new formulation is uglier, it is preferable from a
maintainability and readability standpoint because it explicitly
enumerates the functions we've chosen to expose in our ABI. Changing
this list is non-trivial and requires thought and planning.
(3) is achieved by making it possible to control the extern template declaration
separately from it's definition. Meaning we could add a new definition to
the dylib, wait for it to roll out, then add the extern template
declaration to the header. Similarly, we could remove existing extern
template declarations while still keeping the definition to prevent ABI
breakages.
Summary:
`__has_attribute(fallthough)` -> `__has_attribute(fallthrough)`
This is a follow-up of https://reviews.llvm.org/D72287
Reviewers: EricWF, mclow.lists, Jim
Reviewed By: Jim
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D72314
Add NetBSD to the same feature list as Fuchsia since it matches
in available features, effectively enabling aligned_alloc(),
timespec_get() and C11 features. Remove now-duplicate declaration
of quick_exit() support.
Differential Revision: https://reviews.llvm.org/D71511
This patch de-duplicates most compressed pair constructors
to use the same code in C++11 and C++03.
Part of doing that is deleting the "__second_tag()" and replacing
it with a "__value_init_tag()" which has the same effect, but
allows for the removal of the special "one-arg" first element
constructor.
This patch is intended to have no semantic change.
This change introduces the __default_init_tag to memory, and a corresponding
element constructor to allow for default initialization of either of the pair
values. This is useful for classes such as std::string where most (all)
constructors explicitly initialize the values in the constructor.
Patch by Martijn Vels (mvels@google.com)
Reviewed as https://reviews.llvm.org/D70617
Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.
In future, all warnings disabled for the test suite should require
an attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.
Since C++11, [depr.impldec]:
The implicit definition of a copy constructor as defaulted is deprecated
if the class has a user-declared copy assignment operator or a
user-declared destructor.
At clang HEAD, -Wdeprecated-copy (included by -Wextra) will warn on such instances.
Reviewed By: EricWF
Differential Revision: https://reviews.llvm.org/D71096
Android API level 21 and above have all these functions available, so we
don't need to include our fallback definitions.
Differential Revision: https://reviews.llvm.org/D69983
Summary:
Android added quick_exit()/at_quick_exit() in API level 21,
aligned_alloc() in API level 28, and timespec_get() in API level 29,
but has the other C11 features at all API levels (since they're basically
just coming from clang directly).
_LIBCPP_HAS_QUICK_EXIT and _LIBCPP_HAS_TIMESPEC_GET already existed,
so we can reuse them. (And use _LIBCPP_HAS_TIMESPEC_GET in a few more
places where _LIBCPP_HAS_C11_FEATURES has been used as a proxy. This
isn't correct for Android.)
_LIBCPP_HAS_ALIGNED_ALLOC is added, to cover aligned_alloc() (obviously).
Add a missing std:: before aligned_alloc in a cstdlib test, and remove a
couple of !defined(_WIN32)s now that we're explicitly testing
TEST_HAS_ALIGNED_ALLOC rather than TEST_HAS_C11_FEATURES.
Reviewers: danalbert, EricWF, mclow.lists
Reviewed By: danalbert
Subscribers: srhines, christof, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D69929
With the upcoming introduction of iterator concepts in ranges,
the meaning of "__is_contiguous_iterator" changes drastically.
Currently we intend it to mean "does it have this iterator category",
but it could now also mean "does it meet the requirements of this
concept", and these can be different.
These traits are currently unused because we don't implement ranges.
However, their addition is part of ongoing work to allow libc++
to optimize on user-provided contiguous iterators.
This function has the same behavior as the now-standand std::to_address.
Re-using the name makes the behavior more clear, and in the future it
will allow us to correctly get the raw pointer for user provided pointer
types.
We effectively never want to export that function, which is an
implementation detail of libc++. This was previously tried in
603715c66b and then reverted in 8335dd314f because it caused
linker warnings. These linker warnings should go away now that we
use internal_linkage instead of always_inline to implement per-TU
insulation.
This change would have warned about the bug found in D62451.
No unit tests since the exception should never throw.
Differential Revision: https://reviews.llvm.org/D62452
Same idea as the current algorithm, that is, add (half of the difference between a and b) to a.
But we use a different technique for computing the difference: we compute b - a into a pair of integers that are named "sign_bit" and "diff". We have to use a pair because subtracting two 32-bit integers produces a 33-bit result.
Computing half of that is a simple matter of shifting diff right by 1, and adding sign_bit shifted left by 31. llvm knows how to do that with one instruction: shld.
The only tricky part is that if the difference is odd and negative, then shifting it by one isn't the same as dividing it by two - shifting a negative one produces a negative one, for example. So there's one more adjustment: if the sign bit and the low bit of diff are one, we add one.
For a demonstration of the codegen difference, see https://godbolt.org/z/7ar3K9 , which also has a built-in test.
Differential Revision: https://reviews.llvm.org/D69459
PR13592 was caused by a problem in how to compiler implemented the
__is_convertible_to intrinsic. That problem, reported as PR13591,
was fixed back in 2012. We don't support such old versions of Clang
anyway, so we don't need the library workaround that had been added
to solve PR13592 (while waiting for the compiler fix).
Summary: This patch removes `shared_ptr::make_shared` as it is not part of the standard. This patch also adds __create_with_cntrl_block, which is a help function that can be used in std::allocate_shared and std::make_shared. This is the third patch (out of 4) from D66178.
Reviewers: EricWF, mclow.lists, ldionne
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68805
llvm-svn: 375504
Summary:
In D67316 we added `_LIBCPP_C_HAS_NO_GETS` to signal that the C library
does not provide `gets()`, and added a test for FreeBSD 13 or higher,
using the compiler-defined `__FreeBSD__` macro.
Unfortunately this did not work that well for FreeBSD's own CI process,
since the gcc compilers used for some architectures define `__FreeBSD__`
to match the build host, not the target.
Instead, we should use the `__FreeBSD_version` macro from the userland
header `<osreldate.h>`, which is more fine-grained. See also
<https://reviews.freebsd.org/D22034>.
Reviewers: EricWF, mclow.lists, emaste, ldionne
Reviewed By: emaste, ldionne
Subscribers: dexonsmith, bsdjhb, krytarowski, christof, ldionne, libcxx-commits
Differential Revision: https://reviews.llvm.org/D69174
llvm-svn: 375340
Summary: The implementation of P1152R4 in Clang has resulted in some deprecation warnings appearing in the libc++ and libc++abi test suite. Fix or suppress these warnings.
Reviewers: mclow.lists, EricWF
Subscribers: christof, ldionne, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68879
llvm-svn: 375307
Summary: In my last patch (D67675) I forgot a few variadics. This patch removes the remaining make_shared and allocate_shared C++03 variadics.
Reviewers: ldionne, EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68000
llvm-svn: 373971
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
This was previously committed as r372778 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.
Reviewers: mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
llvm-svn: 373092
Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.
This was previously committed as r372777 and reverted in r372832 due to
the commit breaking LLVM's build in C++14 mode. This issue has now been
addressed.
Reviewers: mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65161
llvm-svn: 372983
Users should only get the assert() macros if they explicitly include
them.
Found after switching from the GNU C++ stdlib to the LLVM C++ stdlib.
llvm-svn: 372963
This declaration was previously missing despite appearing in the
synopsis. Users are still required to include <ostream> to get the
definition of the streaming operator.
llvm-svn: 372909
This also reverts:
- r372778: [libc++] Implement LWG 3158
- r372782: [libc++] Try fixing tests that fail on GCC 5 and older
- r372787: Purge mentions of GCC 4 from the test suite
Reason: the change breaks compilation of LLVM with libc++, for details see
http://lists.llvm.org/pipermail/libcxx-dev/2019-September/000599.html
llvm-svn: 372832
Summary: As suggested by @ldionne in D66178, this patch removes C++03 variadics //only//. Following patches will apply more updates.
Reviewers: ldionne, EricWF, mclow.lists
Subscribers: christof, dexonsmith, libcxx-commits, ldionne
Tags: #libc
Differential Revision: https://reviews.llvm.org/D67675
llvm-svn: 372780
Summary:
LWG 3158 marks the allocator_arg_t constructor of std::tuple as
conditionnally explicit based on whether the default constructors
of the tuple's members are explicitly default constructible.
Reviewers: EricWF, mclow.lists
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65232
llvm-svn: 372778
Summary:
LWG2510 makes tag types like allocator_arg_t explicitly default
constructible instead of implicitly default constructible. It also
makes the constructors for std::pair and std::tuple conditionally
explicit based on the explicit-ness of the default constructibility
for the pair/tuple's elements.
Reviewers: mclow.lists, EricWF
Subscribers: christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D65161
llvm-svn: 372777
std::condition_variable is currently implemented via
pthread_cond_timedwait() on systems that use pthread. This is
problematic, since that function waits by default on CLOCK_REALTIME
and libc++ does not provide any mechanism to change from this
default.
Due to this, regardless of if condition_variable::wait_until() is
called with a chrono::system_clock or chrono::steady_clock parameter,
condition_variable::wait_until() will wait using CLOCK_REALTIME. This
is not accurate to the C++ standard as calling
condition_variable::wait_until() with a chrono::steady_clock parameter
should use CLOCK_MONOTONIC.
This is particularly problematic because CLOCK_REALTIME is a bad
choice as it is subject to discontinuous time adjustments, that may
cause condition_variable::wait_until() to immediately timeout or wait
indefinitely.
This change fixes this issue with a new POSIX function,
pthread_cond_clockwait() proposed on
http://austingroupbugs.net/view.php?id=1216. The new function is
similar to pthread_cond_timedwait() with the addition of a clock
parameter that allows it to wait using either CLOCK_REALTIME or
CLOCK_MONOTONIC, thus allowing condition_variable::wait_until() to
wait using CLOCK_REALTIME for chrono::system_clock and CLOCK_MONOTONIC
for chrono::steady_clock.
pthread_cond_clockwait() is implemented in glibc (2.30 and later) and
Android's bionic (Android API version 30 and later).
This change additionally makes wait_for() and wait_until() with clocks
other than chrono::system_clock use CLOCK_MONOTONIC.<Paste>
llvm-svn: 372016
exceptions are disabled.
The patch was reverted due to some confusion about non-movable types. ie
types
that explicitly delete their move constructors. However, such types do
not meet
the requirement for `MoveConstructible`, which is required by
`std::vector`:
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
llvm-svn: 371867
Summary:
In https://svnweb.freebsd.org/changeset/base/351659 @emaste removed gets() from
FreeBSD 13's libc, and our copies of libc++ and libstdc++. In that change, the
declarations were simply deleted, but I would like to propose this conditional
test instead.
Reviewers: EricWF, mclow.lists, emaste
Reviewed By: mclow.lists
Subscribers: krytarowski, christof, ldionne, emaste, libcxx-commits
Differential Revision: https://reviews.llvm.org/D67316
llvm-svn: 371324
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.
llvm-svn: 371068
This is needed anytime we need to clamp an arbitrary floating point
value to an integer type.
Thanks to Eric Fiselier for the patch.
Differential Revision: https://reviews.llvm.org/D66836
llvm-svn: 370891
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.
llvm-svn: 370796
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
llvm-svn: 370502
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
llvm-svn: 370240
_LIBCPP_HAS_THREAD_API_EXTERNAL is not defined.
When it is defined they will be declared by the
__external_threading header instead.
Differential revision: https://reviews.llvm.org/D66518
llvm-svn: 369537
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
llvm-svn: 369422
A new clang warning introduced in r367497 was complaining about
the change in value.
Thanks to Brian Cain for the patch.
Differential Revision: https://reviews.llvm.org/D66422
llvm-svn: 369393
The commit being reverted caused segfaults when building
with libc++ and GCC (and possibly other configurations).
Differential Revision: https://reviews.llvm.org/D62868
llvm-svn: 369270
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.
llvm-svn: 368880
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
llvm-svn: 368703
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
llvm-svn: 368664
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
llvm-svn: 368599
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.
llvm-svn: 368547
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.
llvm-svn: 368088
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
llvm-svn: 367903
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).
llvm-svn: 367770
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.
llvm-svn: 367749
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.
llvm-svn: 367631
Petr Hosek