When running libc++ tests on a remote machine via SSH, we can encounter
a 'Permission denied' error.
Fix this with plain old 'chmod +x <executable>'.
Thanks to Sergej Jaskiewicz for the patch.
Differential Revision: https://reviews.llvm.org/D69170
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
* Add the conventional `return 0` to `main` in `variant.assign/conv.pass.cpp` and `variant.ctor/conv.pass.cpp`
* Fix some MSVC signed-to-unsigned conversion warnings by replacing `int` literarls with `unsigned int` literals
llvm-svn: 374723
`make_optional<string>(4, 'X')` passes `4` (an `int`) as the first argument to `string`'s `(size_t, charT)` constructor, triggering a signed/unsigned mismatch warning when compiling with MSVC at `/W4`. The incredibly simple fix is to instead use an unsigned literal (`4u`).
llvm-svn: 374684
Handle the case when libc++abi and libunwind are being built together
with libc++ in the runtimes build. This logic was used in the previous
implementation but dropped in r374116.
Differential Revision: https://reviews.llvm.org/D68791
llvm-svn: 374510
`sizeof(std::any) - sizeof(void*)` is correct for both libc++ and the MSVC standard library.
Differential Revision: https://reviews.llvm.org/D68756
llvm-svn: 374407
* Silence unused-local-typedef warnings: `map.cons/assign_initializer_list.pass.cpp` (and the `set.cons` variant) uses a local typedef only within `LIBCPP_ASSERT`s, so clang diagnoses it as unused when testing non-libc++.
* Add missing include: `c.math/abs.pass.cpp` uses `std::numeric_limits` but failed to `#include <limits>`.
* Don't test non-type: A "recent" change to `meta.trans.other/underlying_type.pass.cpp` unconditionally tests the type `F` which is conditionally defined.
* Use `hash<long long>` instead of `hash<short>` with `int` in `unordered_meow` deduction guide tests to avoid truncation warnings.
* Convert `3.14` explicitly in `midpoint.float.pass` since MSVC incorrectly diagnoses `float meow = 3.14;` as truncating.
Differential Revision: https://reviews.llvm.org/D68681
llvm-svn: 374248
Summary:
This allows the linker script generation to query CMake properties
(specifically the dependencies of libc++.so) instead of having to
carry these dependencies around manually in global variables. Notice
the removal of the LIBCXX_INTERFACE_LIBRARIES global variable.
Reviewers: phosek, EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D68343
llvm-svn: 374116
It turns out that r374056 broke _some_ build bots again, specifically
the ones using sanitizers. Instead of trying to link the right system
libraries to the benchmarks bit-by-bit, let's just link exactly the
system libraries that libc++ itself needs.
llvm-svn: 374079
We tried doing that previously (in r373487) and failed (reverted in
r373506) because the benchmarks needed to link against system libraries
and relied on libc++'s dependencies being propagated. Now that this has
been fixed (in r374053), this commit marks the system libraries as
PRIVATE dependencies of libc++.
llvm-svn: 374056
Since the benchmarks build with -nostdlib, they need to manually link
against some system libraries that are used by the benchmarks and the
GoogleBenchmark library itself.
Previously, we'd rely on the fact that these libraries were linked
through the PUBLIC dependencies of cxx_shared/cxx_static. However,
if we were to make these dependencies PRIVATE (as they should be
because they are implementation details of libc++), the benchmarks
would fail to link. This commit remediates that.
llvm-svn: 374053
It's better style to use PRIVATE when linking libraries to executables,
and it doesn't make a difference since executables don't need to propagate
their link-time dependencies anyway.
llvm-svn: 374050
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
If you explicitly set LIBCXX_ENABLE_EXPERIMENTAL_LIBRARY to OFF, your
project will fail to configure because the cxx_experimental target
doesn't exist.
llvm-svn: 373809
Also, set those flags for the cxx_experimental target. Otherwise,
cxx_experimental doesn't build properly when neither the static nor
the shared library is compiled (yes, that is a weird setup).
llvm-svn: 373808
Summary:
The current version of the pretty printers are not python3 compatible,
so turn them off by default until sufficiently improved.
Reviewers: MaskRay, tamur
Subscribers: mgorny, christof, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68477
llvm-svn: 373796
The first commit removed the workaround in a old script.
This patch removes it in the file actually used by the bots.
I have no idea if this is still needed, but removing the
workaround seems like the easiest way to test.
I'll revert this change if the bots go red.
llvm-svn: 373653
I have no idea if this is still needed, but removing the
workaround seems like the easiest way to test.
I'll revert this change if the bots go red.
llvm-svn: 373650
This allows propagating the include automatically to targets that
depend on one of the libc++ targets such as the benchmarks. Note
that the GoogleBenchmark build itself still needs to manually specify
the -include, since I don't know of any way to have an external project
link against one of the libc++ targets (which would propagate the -include
automatically).
llvm-svn: 373631
In both Python 2 and Python 3, gdb.Value.string returns a 'str'. We just
need to delete a `encode("utf-8")` which would return a 'bytes' in
Python 3.
llvm-svn: 373570
This commit follows the trend of doing things per-target instead of
modifying the C++ flags globally. It does so for visibility-related
flags, other basic build flags and Windows-specific flags.
llvm-svn: 373517
This is part of a larger shift to move to per-target settings and
eradicate global variables from the CMake build. I'm starting small
with warnings only because those are easy to transition over and I
want to see how it pans out, but we can handle all flags like exceptions
and RTTI in the future.
llvm-svn: 373511
It turns out the benchmarks need to link against those libraries
explicitly too, so CMake's propagation of PUBLIC dependencies is
used.
llvm-svn: 373506
Summary:
I haven't managed a small reproduction for this bug, it involves
complicated and deeply nested data structures with a wide variety
of pretty printers. But in general, we shouldn't be combining
gdb's command line interface (via gdb.execute) with pretty-printers.
Subscribers: christof, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68306
llvm-svn: 373402
In reality, this workaround is for the fact that LIBCXX_CXX_ABI=libcxxabi
can't be specified on Linux, since libc++abi isn't shipped with the system.
Since the build bots explicitly specify LIBCXX_CXX_ABI=libcxxabi, they fail
unless we apply the workaround.
llvm-svn: 373385
I tried applying D63883 three times and could never get around to
making it work. I'm giving up on that for now, but soon this should
be irrelevant anyway since all builds will move to the monorepo
(where we're always using the in-tree libc++abi unless explicitly
specified otherwise).
llvm-svn: 373384
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
We don't support GCC 4 and older according to the documentation, so
we should pretend it doesn't exist.
This is a re-application of r372787.
llvm-svn: 372916
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
Summary:
This patch is an exact duplicate of https://reviews.llvm.org/D65609, except
that it uses the newly introduced testing framework to detect if gdb is present
so that the tests won't fail on machines without gdb.
Reviewers: echristo, EricWF
Subscribers: christof, ldionne, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D67238
llvm-svn: 371131
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
The visibility annotations in libc++ are not quite right for GCC, which
results in symbols not being exported when -fvisibility=hidden is used.
To fix the GCC build bots, this commit reverts to the previous state of
not building with hidden visibility on GCC.
In the future, we can build with hidden visibility all the time and
export symbols explicitly using a list. See https://llvm.org/D66970
for one take at this.
llvm-svn: 370926
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
This patch fixes some typos and other small errors in
directory_iterator.cpp that prevented this file from being compiled for
Win32.
Patch by Stefan Schmidt <thrimbor.github@gmail.com>!
Differential Revision: https://reviews.llvm.org/D66986
llvm-svn: 370599
Summary: Also add a test suite.
Reviewers: EricWF
Subscribers: christof, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D65609
Run a pep8 formatter.
Run pep8 formatter.
Convert to PEP8, address other comments from code review.
llvm-svn: 370551
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
This was reported as part of a bug report that ended up being a
duplicate for r340609, but I'm adding the test case since it's
ever so slightly different from what we had before.
llvm-svn: 370109
Popen.communicate() method in Python 2 returns a pair of strings, and in
Python 3 it returns a pair of byte-like objects unless universal_newlines
is set to True. This led to an error when using Python 3. With this patch,
merge_archives.py works fine with Python 3.
Thanks to Sergej Jaskiewicz for the patch.
Differential Revision: https://reviews.llvm.org/D66649
llvm-svn: 369764
The build should generally be quiet if there are no errors,
and this script has been around long enough that we can remove
the log output. If we ever need to debug something with this script,
we can put back the logging then.
Differential Revision: https://reviews.llvm.org/D66594
llvm-svn: 369757
In r369429, I hoisted a floating point computation to a variable in order
to remove a warning. However, it turns out this doesn't play well with
floating point arithmetic. This commit reverts r369429 and instead casts
the result of the floating point computation to remove the warning.
Whether hoisting the computaiton to a variable should give the same
result can be investigated independently.
llvm-svn: 369693
_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
On systems where sizeof(long) == sizeof(int)
the current tests failed. This commit updates
those tests to work on all systems.
std::abs has specific long specializations
which can be used instead.
llvm-svn: 369437
By stashing the computation of `E::max() - E::min()` in a variable, we
avoid the warning introduced in r367497. Note that we use `auto` to
avoid having to deduce the type of the computation, which is not a
problem since Clang provides `auto` as an extension even in C++03 (and
we disable warnings related to using C++11 extensions in the test suite).
llvm-svn: 369429
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
In r368882, I enabled those tests for all AppleClang's above version 9.
However, it turns out that the feature is only supported starting with
AppleClang 10.0.1, not AppleClang 10.0.0. This commit fixes that hole.
llvm-svn: 369409
If the compiler is (for example) AppleClang 10.0.1, we would previously
populate the following lit features:
apple-clang
apple-clang-10
apple-clang-10.0
This patch additionally populates a feature called 'apple-clang-10.0.1',
which allows more precise enabling/disabling of tests.
llvm-svn: 369406
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
Like CTAD for std::unordered_set, AppleClang 9's support for CTAD is
insufficient. I suspect the corresponding LLVM Clang is broken too,
but we don't seem to have testers using that Clang.
llvm-svn: 368911
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
Summary:
Quote the value of environment variables when passing them to the SSH
client in SSHExecutor in libc++'s lit utilities. Without the quotes,
an environment variable like FOO="buzz bar" gets passed incorrectly
like this, ssh env FOO=buzz bar, which causes bar to be treated as a
command to run, not part of the environment variable value.
We ran into this when using SSHExecutor to do bringup of our CUDA
libcu++ port on an embedded aarch64 system.
Patch by Bryce Adelstein Lelbach.
Differential Revision: https://reviews.llvm.org/D65960
llvm-svn: 368317
This commit adds a __pstl_config_site header that contains the value of
macros specified at CMake configuration time. It works similarly to
libc++'s __config_site header, except we always include it as a separate
file instead of concatenating it to the main configuration header.
It is necessary to thread the includes for that header into libc++'s
lit configuration, otherwise we'd be requiring an installation step
prior to running the test suite.
llvm-svn: 368284
This also reverts "[libc++] Remove temporary hack for D63883".
Clearly, I don't understand how the Linux build bots are configured.
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 368238
Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.
More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.
This is a re-application of r365222 that had been reverted in r365233
and then r365359 because it broke the build bots. The build bots
should now specify explicitly what ABI library they want to use
(libc++abi), so this commit should now be OK to merge. It takes a while
for build bots to pick up configuration changes, which is why this failed
the last time around.
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 368213
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
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.
llvm-svn: 367605
[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.
llvm-svn: 367316
The test configuration contained a bug where we only raised
the __config_site commands to the command line if modules were
enabled for all of the libc++ tests. However there are special
modules-only tests, and these tests weren't getting the correct
defines.
This patch corrects that issue.
llvm-svn: 367267
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
llvm-svn: 367183
Summary:
On AIX psutil can run into problems with permissions to read the process
tree, which causes problems for python timeout tests which need to kill off
a test and it's children.
This patch adds a workaround by invoking shell via subprocess and using a
platform specific option to ps to list all the descendant processes so we can
kill them. We add some checks so lit can tell whether timeout tests are
supported with out exposing whether we are utilizing the psutil
implementation or the alternative.
Reviewers: hubert.reinterpretcast, andusy, davide, delcypher
Reviewed By: delcypher
Subscribers: davide, delcypher, christof, lldb-commits, libcxx-commits, llvm-commits
Tags: #lldb, #libc, #llvm
Differential Revision: https://reviews.llvm.org/D64251
llvm-svn: 366912
This is a cherrypick of D64237 onto llvm/utils/benchmark and
libcxx/utils/google-benchmark.
Differential Revision: https://reviews.llvm.org/D65142
llvm-svn: 366868
The constructors for std::pair and std::tuple have been made conditionally
explicit, however the synopsis in the headers do not reflect that.
llvm-svn: 366735
r362048 added support for ELF dependent libraries, but broke Android
build since Android does not have libpthread. Remove the dependency on
the Android build.
Differential Revision: https://reviews.llvm.org/D65098
llvm-svn: 366734
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
llvm-svn: 366730
libc++'s lit configuration infers the C++ language dialect when it is
not provided by checking which -std= flags that a compiler supports.
GCC 5 and GCC 6 have a -std=c++17 flag, however, they do not have full
C++17 support. The lit configuration has hardcoded logic that removes
-std=c++1z as an option to test for GCC < 7, but not -std=c++17.
This leads to a bunch of failures when running libc++ tests with GCC 5
or GCC 6. This patch adds -std=c++17 to the list of flags that are
discarded for GCC < 7 by lit's language dialect inference.
Thanks to Bryce Adelstein Lelbach for the patch.
Differential Revision: https://reviews.llvm.org/D62874
llvm-svn: 366700
Some minor versions of AppleClang 9 appear not to fail the test. It's
such a mess that the only sane thing to do is to mark the test as
UNSUPPORTED.
llvm-svn: 366606
This reverts r366593, which caused unforeseen breakage on the build bots.
I'm reverting until the problems have been figured out and fixed.
llvm-svn: 366603
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
llvm-svn: 366593
Without the link flags, the test always fails on Linux. For some reason,
however, it works on Darwin -- which is why it wasn't caught at first.
llvm-svn: 366579
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
llvm-svn: 366567
In r361572, we introduced library support for C++20 destroying delete
and decided to only define the library feature-test macro when the
compiler supports the underlying language feature. This patch reworks
the tests to mirror that.
llvm-svn: 366263
The tests for unordered_set and unordered_multiset were missing UNSUPPORTED
markup for Apple Clang 9.1, which is still being used on some CI bots.
llvm-svn: 366259
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.
llvm-svn: 366033
The standard disallows narrowing conversions when constructing a variant.
This is checked by attempting to perform braced initialization of the
destination type from the argument type. However, braced initialization
can force the compiler (mostly clang) to eagerly instantiate the
constructors of the destintation type -- which can lead to errors in
a non-immediate context.
However, as variant is currently specified, the narrowing checks only
observably apply when the destination type is arithmetic. Meaning we can
skip the check for class types. Hense avoiding the hard errors.
In order to cause fewer build breakages, this patch avoids the narrowing
check except when the destination type is arithmetic.
llvm-svn: 366022
Previously we implemented all one trillion tuple-like constructors using
a single generic overload. This worked fairly well, except that it
differed in behavior from the standard version because it didn't
consider both T&& and T const&. This was observable for certain
types.
This patch addresses that issue by splitting the generic constructor
in two. We now provide both T&& and T const& versions of the
tuple-like constructors (sort of).
llvm-svn: 365973
The paper P0608R3 - "A sane variant converting constructor" disallows
narrowing conversions in variant. It was meant to address this
surprising problem:
std::variant<std::string, bool> v = "abc";
assert(v.index() == 1); // constructs a bool.
However, it also disables every potentially narrowing conversion. For
example:
variant<unsigned> v = 0; // ill-formed
variant<string, double> v2 = 42; // ill-formed (int -> double narrows)
These latter changes break code. A lot of code. Within Google it broke
on the order of a hundred thousand target with thousands of root causes
responsible for the breakages.
Of the breakages related to the narrowing restrictions, none of them
exposed outstanding bugs. However, the breakages caused by boolean
conversions (~13 root causes), all but one of them were bugs.
For this reasons, I am adding a flag to disable the narrowing conversion
changes but not the boolean conversions one.
One purpose of this flag is to allow users to opt-out of breaking changes
in variant until the offending code can be cleaned up. For non-trivial
variant usages the amount of cleanup may be significant.
This flag is also required to support automated tooling, such as
clang-tidy, that can automatically fix code broken by this change.
In order for clang-tidy to know the correct alternative to construct,
it must know what alternative was being constructed previously, which
means running it over the old version of std::variant.
Because this change breaks so much code, I will be implementing the
aforementioned clang-tidy check in the very near future.
Additionally I'm plan present this new information to the committee so they can
re-consider if this is a breaking change we want to make.
I think libc++ should very seriously consider pulling this change
before the 9.0 release branch is cut. But that's a separate discussion
that I will start on the lists.
For now this is the minimal first step.
llvm-svn: 365960
The buildbots were changed to pass -DLIBCXX_CXX_ABI=libcxxabi, but
they don't provide an include path for the library, so cxxabi.h is
never found while building libc++.
This is a temporary change until the buildbots are updated or until
D63883 lands in a form that unbreaks the bots
llvm-svn: 365847
When assigning an initializer list into set/map, libc++ would
leak memory if the initializer list contained equivalent keys
because we failed to check if the insertion was successful.
llvm-svn: 365840
Rather than building up a list to iterate over later, just create multiple
install commands based on the configuration. This makes it easier to see what
is getting installed and allows for the install handling to be centralised. NFC
llvm-svn: 365562
Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.
More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.
This is a re-application of r365222 that had been reverted in r365233
because it broke the build bots. However, the build bots now specify
explicitly what ABI library they want to use (libc++abi), so this
commit should now be OK to merge.
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 365326
The implementations of __libcpp_mutex_destroy and __libcpp_condvar_destroy
are already NOPs, so this optimization is safe to perform.
See r365273 and PR27658 for more information.
llvm-svn: 365281
Currently std::mutex has a constexpr constructor, but a non-trivial
destruction.
The constexpr constructor is required to ensure the construction of a
mutex with static storage duration happens at compile time, during
constant initialization, and not during dynamic initialization.
This means that static mutex's are always initialized and can be used
safely during dynamic initialization without the "static initialization
order fiasco".
A trivial destructor is important for similar reasons. If a mutex is
used during dynamic initialization it might also be used during program
termination. If a static mutex has a non-trivial destructor it will be
invoked during termination. This can introduce the "static
deinitialization order fiasco".
Additionally, function-local statics emit a guard variable around
non-trivially destructible types. This results in horrible codegen and
adds a runtime cost to every call to that function. non-local static's
also result in slightly worse codegen but it's not as big of a problem.
Example codegen can be found here: https://goo.gl/3CSzbM
Note: This optimization is not safe with every pthread implementation.
Some implementations allocate on the first call to pthread_mutex_lock
and free the allocation in pthread_mutex_destroy.
Also, changing the triviality of the destructor is not an ABI break.
At least to the best of my knowledge :-)
llvm-svn: 365273
Summary:
Otherwise, when libcxxabi is not an enabled project in the monorepo, we
get a link error because we try to link against non-existent cxxabi_shared.
More generally, we shouldn't change the behavior of the build based on
implicit things like whether a file happens to be at a specific path or
not.
Reviewers: EricWF
Subscribers: mgorny, christof, jkorous, dexonsmith, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D63883
llvm-svn: 365222
types.
It seems some people like to write types that can explicitly convert
to anything, but cannot be used to explicitly construct anything.
This patch makes tuple tolerate such types, as is required
by the standard.
llvm-svn: 365074
Summary:
This fixes a clang-tidy warning when building something that uses
this file.
Reviewers: mclow.lists, EricWF
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D43226
llvm-svn: 364799
when _LIBCPP_ABI_UNSTABLE is defined.
User defined _LIBCPP_ABI_NAMESPACE will still be respected,
but the default version namespace in unstable mode will be the libc++ version
(Currently '__9000').
Previously `_LIBCPP_ABI_VERSION` and `_LIBCPP_ABI_NAMESPACE` were
`1` and `__1` respectively, whuch conflicted with the stable ABI
llvm-svn: 364354
Use binary mode to read test files in libcxx LibcxxTestFormat class.
This ensures that tests are read correctly independently of encoding,
and therefore fixes UnicodeDecodeError when file is opened in Python 3
that defaults to pure ASCII encoding.
Technically this could be also fixed via conditionally appending
encoding argument when opening the file in Python 3. However, since
the code in question only searches for fixed ASCII substrings reading
it in binary mode is simpler and more universal.
Differential Revision: https://reviews.llvm.org/D63346
llvm-svn: 364170
The new meta-programming primitives are lower cost than the old versions. This patch removes those old versions and switches libc++ to use the new ones.
llvm-svn: 364160
David Blaikie