First, add a TEST_HAS_QUICK_EXIT macro to mirror other C11 features like
TEST_HAS_ALIGNED_ALLOC, and update the tests for that.
Second, get rid of TEST_HAS_C11_FEATURES and _LIBCPP_HAS_C11_FEATURES,
which were only used to ensure that feature macros don't get out of
sync between <__config> and "test_macros.h". This is not necessary
anymore, since we have tests for each individual macro now.
Python 2.7 fails with TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
if you pass None as the prefix argument to NamedTemporaryFile.
Reviewed By: ldionne, bjope, #libc
Differential Revision: https://reviews.llvm.org/D84595
This avoids issues when building the dylib for deployment targets that
don't support aligned allocation, where Clang normally triggers an
error to warn users their code would break at runtime when back-deployed.
Since we're building the dylib itself, which contains the aligned
allocation functions, we don't want to trigger that error.
Differential Revision: https://reviews.llvm.org/D84418
This change replaces std::make_unique with manual construction of
std::unique_ptr to make the tests compatible with C++11
(std::make_unique is a C++14 feature).
libc++ supports std::unique_ptr and std::shared_ptr even in C++03 but
with some limitations: unique_ptr_array.pass.cpp and
shared_ptr_arg.pass.cpp fail to compile in C++03 mode and need to be
disabled.
Differential Revision: https://reviews.llvm.org/D84394
The lambda being used to check whether locales are supported was always
passing the value of alts from the last loop iteration due to the way that
python lambda captures work. Fix this by using a default argument capture.
To help debug future similar issues I also added a prefix to the config
test binary indicating which locale is being tested.
I originally found this issue when implementing a new executor that simply
collects test binaries in a given directory and was surprised to see many
additional executables other than the expected test binaries. I therefore
added the locale prefix to the test binaries and noticed that they were all
checking for cs_CZ.ISO8859-2.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D84040
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
This allows simplifying the implementation of barriers.
This is a re-commit of 1ac403bd14, which had to be reverted in
64a9c944fc because the minimum CMake version wasn't high enough.
Now that we've upgraded, we can do this.
Differential Revision: https://reviews.llvm.org/D75243
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
If we use the default of None, we get a python exception in
find_and_diagnose_missing() instead of printing a sensible error message.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D84342
Adding a positional argparse.ONE_OR_MORE arguments will correctly remove
the "--" separator after --env and parse only the command. This also has
the advantage that misspelled flags raise an argparse error rather than
silently being added to the command to be executed.
I discovered this while adding a new commandline option to ssh.py to allow
passing additional arguments to the scp/ssh commands since this is required
for our CHERI CI where we need to pass `-F <custom_config_file>` to each
ssh/scp command to set various arguments such as the localhost port, usage
of controlmaster, etc. to speed up connections to our emulated QEMU systems.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D84096
Summary:
weak_ptr has two pointers (more than the 4 bytes limit), so it will not be returned in registers on ARM, even if it is trivial.
The test, therefore, will fail on ARM.
Reviewers: #libc!
Subscribers: kristof.beyls, danielkiss, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D84200
This patch adds Clang's new (and GCC's old) -Wsuggest-override to the warning flags for the LLVM build. The warning is a stronger form of -Winconsistent-missing-override which warns _everywhere_ that override is missing, not just in places where it's inconsistent within a class.
Some directories in the monorepo need the warning disabled for compatibility's, or sanity's, sake; in particular, libcxx/libcxxabi, and any code implementing or interoperating with googletest, googlemock, or google benchmark (which do not themselves use override). This patch adds -Wno-suggest-override to the relevant CMakeLists.txt's to accomplish this.
Differential Revision: https://reviews.llvm.org/D84126
Some time ago, I introduced shortcut features like dylib-has-no-shared_mutex
to encode whether the deployment target supported shared_mutex (say). This
made the test suite annotations cleaner.
However, the problem with building Lit features on top of other Lit
features is that it's easier for them to become stale, especially when
they are generated programmatically. Furthermore, it makes the bar for
defining configurations from scratch higher, since more features have
to be defined. Instead, I think it's better to put the XFAILs in the
tests directly, which allows cleaning them up with a simple grep.
Instead of detecting it automatically but also allowing for the setting
to be specified explicitly, always detect whether exceptions are enabled
based on whether -fno-rtti (or equivalent) is used. It's less confusing
to have a single way of tweaking that knob.
This change follows the lead of 71d88cebfb.
Instead of having complex logic around how to include the libc++ headers
and __config_site, handle that by defining cxx-headers as an INTERFACE
library and linking against it. After this patch, linking against cxx-headers
is sufficient to get the right __config_site include and include paths
for libc++.
Differential Revision: https://reviews.llvm.org/D82702
This allows passing parameters to the test suites without using
LLVM_LIT_ARGS. The problem is that we sometimes want to set some
Lit arguments on the CMake command line, but the Lit parameters in
a CMake cache file. If the only knob to do that is LLVM_LIT_ARGS,
the command-line entry overrides the cache one, and the parameters
set by the cache are ignored.
This fixes a current issue with the build bots that they completely
ignore the 'std' param set by Lit, because other Lit arguments are
provided via LLVM_LIT_ARGS on the CMake command-line.
Thanks to @lewissbaker who pointed out the unnecessary condition in
https://reviews.llvm.org/D81954#inline-756872. Since this codepath does not
make use of `swap` anyway (that codepath is a different branch), we can safely
remove this condition and produce better codegen when all types are nothrow
movable but are potentially-throwing swappable.
See codegen in https://gcc.godbolt.org/z/uDFZjz
Reviewed By: ldionne, #libc
Differential Revision: https://reviews.llvm.org/D83274
There used to be a workaround where we'd pretend that GCC 5 didn't support
C++14 because it doesn't implement it properly. Since that workaround has
been removed (in 1eb211ada1), we need to mark a few individual tests as
failing with GCC 5.
Summary:
Modifies the algorithm sort bench:
- shows sorting time per element, instead of sorting time per array.
This would make comparison between different sizes of arrays easier.
- adds std::pair benchmark cases.
- uses a large number of arrays to benchmark, instead of repeatedly sorting the same array.
* sorting the same array again and again would not show actual sorting performance over randomized data sets.
Reviewers: EricWF, #libc, mvels
Reviewed By: EricWF, #libc, mvels
Subscribers: mgrang, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D81770
Instead of detecting it automatically (in libc++) and relying on
_LIBCXXABI_NO_EXCEPTIONS being set explicitly (in libc++abi), always
detect whether exceptions are enabled automatically.
This commit also removes support for specifying -D_LIBCPP_NO_EXCEPTIONS
and -D_LIBCXXABI_NO_EXCEPTIONS explicitly -- those should just be inferred
from using -fno-exceptions (or an equivalent flag).
Allowing both -D_FOO_NO_EXCEPTIONS to be provided explicitly and trying
to detect it automatically is just confusing, especially since we did
specify it explicitly when building libc++abi. We should have only one
way to detect whether exceptions are enabled, but it should be robust.
As announced on libcxx-dev at [1], the old libc++ testing format is being
removed in favour of the new one. Follow-up commits will clean up the
code that is dead after the removal of this option.
[1]: http://lists.llvm.org/pipermail/libcxx-dev/2020-June/000885.html
Since we can always find the rest of the LLVM tree, we can always run the
tests in the standalone mode. Do it so that the default behavior is the
same in the standalone and non-standalone modes.
Since we require that libc++ is built as part of the monorepo layout, we
can assume the path of the rest of LLVM and avoid requiring that LLVM_PATH
be set explicitly.
Doing so doesn't work reliably, since it relies on LLVM_* implementation
detail variables being set. Furthermore, since we rely on the lit.site.cfg
being generated, running the tests requires LIBCXX_INCLUDE_TESTS=ON anyway.
We've decided to move away from that by requiring that libc++ is built
as part of the monorepo a while ago. This commit removes code pertaining
to that unsupported use case and produces a clear error when the user
violates that.
In fact, building outside of the monorepo will still work as long as
LLVM_PATH is pointing to the root of the LLVM project, although that
is not officially supported.
The runtimes build includes libcxx/include/CMakeLists.txt directly instead
of going through the top-level CMake file. This not-very-hygienic inclusion
caused some variables like LIBCXX_BINARY_DIR not to be defined properly,
and the config_site generation logic to fail after landing 53623d4aa7.
This patch works around this issue by defining the missing variables.
However, the proper fix for this would be for the runtimes build to
always go through libc++'s top-level CMakeLists.txt. Doing otherwise
is unsupported.
Before this patch, the __config_site header was only generated when at
least one __config_site macro needed to be defined. This lead to two
different code paths in how libc++ is configured, depending on whether
a __config_site header was generated or not. After this patch, the
__config_site is always generated, but it can be empty in case there
are no macros to define in it.
More context on why this change is important
--------------------------------------------
In addition to being confusing, this double-code-path situation lead to
broken code being checked in undetected in 2405bd6898, which introduced
the LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT CMake setting. Specifically,
the _LIBCPP_HAS_MERGED_TYPEINFO_NAMES_DEFAULT <__config_site> macro was
supposed NOT to be defined unless LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT
was specified explicitly on the CMake command line. Instead, what happened
is that it was defined to 0 if it wasn't specified explicitly and a
<__config_site> header was generated. And defining that macro to 0 had
the important effect of using the non-unique RTTI comparison implementation,
which changes the ABI.
This change in behavior wasn't noticed because the <__config_site> header
is not generated by default. However, the Apple configuration does cause
a <__config_site> header to be generated, which lead to the wrong RTTI
implementation being used, and to https://llvm.org/PR45549. We came close
to an ABI break in the dylib, but were saved due to a downstream-only
change that overrode the decision of the <__config_site> for the purpose
of RTTI comparisons in libc++abi. This is an incredible luck that we should
not rely on ever again.
While the problem itself was fixed with 2464d8135e by setting
LIBCXX_HAS_MERGED_TYPEINFO_NAMES_DEFAULT explicitly in the Apple
CMake cache and then in d0fcdcd28f by making the setting less
brittle, the point still is that we should have had a single code
path from the beginning. Unlike most normal libraries, the macros
that configure libc++ are really complex, there's a lot of them and
they control important properties of the C++ runtime. There must be
a single code path for that, and it must be simple and robust.
Differential Revision: https://reviews.llvm.org/D80927
Since we're using an empty top-level CMakeLists.txt instead of the CMakeLists.txt
inside llvm/, we don't need to specify LLVM_INCLUDE_BENCHMARKS anymore.
We use the _LIBCPP_ABI_ALTERNATE_STRING_LAYOUT macro for that now instead.
I did leave a check behind to make sure that nobody was still using the old
macro name. I'll remove it a couple of months down the road.
Summary:
https://reviews.llvm.org/D82029 introduced the non-throw check for final_suspend(). There are a few tests I missed in that patch.
Fixing them here.
Reviewers: #libc, lewissbaker, modocache, ldionne
Reviewed By: #libc, ldionne
Subscribers: dexonsmith, modocache, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D82338
Similar to <concepts>, we need to protect the header and test against
inclusion and being run if concepts aren't supported by the compiler.
Differential Revision: https://reviews.llvm.org/D82171
Summary:
This change adds local 'end' and 'pos' variables for the main loop inmstead of using the ConstructTransaction variables directly.
We observed that not all vector initialization and resize operations got properly vectorized, i.e., (partially) unrolled into XMM stores for floats.
For example, `vector<int32_t> v(n, 1)` gets vectorized, but `vector<float> v(n, 1)`. It looks like the compiler assumes the state is leaked / aliased in the latter case (unclear how/why for float, but not for int32), and because of this fails to see vectorization optimization?
See https://gcc.godbolt.org/z/UWhiie
By using a local `__new_end_` (fixed), and local `__pos` (copied into __tx.__pos_ per iteration), we offer the compiler a clean loop for unrolling.
A demonstration can be seen in the isolated logic in https://gcc.godbolt.org/z/KoCNWv
The com
Reviewers: EricWF, #libc!
Subscribers: libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D82111
When testing libc++ for our cross-compiled CheriBSD target we specify an
explicit LIBCXX_CXX_ABI_INCLUDE_PATHS for libcxxrt. The hardcoded path
/usr/include/c++/v1 was introduced in 61e89737c5
and overrides any value passed on the CMake command line. Fix this by using
it as a fallback rather than a fixed default value.
Reviewed By: #libc, ldionne
Differential Revision: https://reviews.llvm.org/D82095
Before this patch, the libc++ test suite first loads lit.site.cfg
(generated by CMake), and then lit.cfg. It's also possible to load
lit.cfg before lit.site.cfg and to point to a custom lit.site.cfg
file using '--param=libcxx_site_config'. However, in that case, lit.cfg
still relies on the site configuration filling up the 'config' object
like the default lit.site.cfg file does, which isn't flexible enough.
This commit simplifies the setup by having just a single Lit site config
file per CMake configuration, and always loading exactly that config file.
However, the config file to use can be selected when setting up CMake via
the LIBCXX_TEST_CONFIG setting. Furthermore, the site configs are entirely
standalone, which means that a new site config can be added that doesn't
need to conform what's expected by config.py.
Differential Revision: https://reviews.llvm.org/D81846
Summary:
In the case where `swap` is `noexcept`, we should avoid the extension to provide strong-exception guarantee.
Fixes https://bugs.llvm.org/show_bug.cgi?id=46342
Reviewers: #libc, ldionne
Reviewed By: #libc, ldionne
Subscribers: dexonsmith, mclow.lists, miscco, ldionne, zoecarver, libcxx-commits
Tags: #libc
Differential Revision: https://reviews.llvm.org/D81954
The Standard documents the signature of std::advance as
template <class Iter, class Distance>
constexpr void advance(Iter& i, Distance n);
Furthermore, it does not appear to put any restriction on what the type
of Distance should be. While it is understood that it should usually
be std::iterator_traits::difference_type, I couldn't find any wording
that mandates that. Similarly, I couldn't find wording that forces the
distance to be a signed type.
This patch changes std::advance to accept any type in the second argument,
which appears to be what the Standard mandates. We then coerce it to the
iterator's difference type, but that's an implementation detail.
Differential Revision: https://reviews.llvm.org/D81425
The commit was reverted in 43c4afb56f because it broke the Windows to
Linux cross-compilation build bots. The issue turned out to be that the
bots were setting the LIBCXX_EXECUTOR incorrectly. This has been fixed
now and verified with the bot owners.
Note that this is only a partial re-application of the commit, since
non-problematic parts of the commits have already been re-applied earlier.
This is useful for checking runtime properties of the target system.
This is a partial re-application of 3ea9450bda. This part was tested
to work on a Windows host with a SSH executor.
That test is already only enabled if LIBCXX_TEST_GDB_PRETTY_PRINTERS is
enabled, which isn't the default. If someone turns on that option on
Windows, they should be able to run the test and see whatever failure
happens.
Louis Dionne