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
Louis Dionne