clang-19 changed how Arm triples were normalised and so while we
supported 18 and 19, we could not hard code the path here.
Now that Linaro's bots are running clang-19, and libcxx is going to drop
clang-18 support (https://github.com/llvm/llvm-project/pull/130142) I
have simplified it by hard coding the path again.
I also looked into why this exists in the first place. It was added in
https://reviews.llvm.org/D154246 but not questioned at the time.
It is due to the way we build compiler-rt, which is due to the final
layout we need in the install:
1. The builtins library must be called libclang_rt.builtins.a for clang
to find it. There must not be an architecture name in the filename.
2. That builtins library must be directly in lib/, next to picolib's
installed files.
To achieve number 1 we must set LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON.
However, that causes the file to be installed in a per-target dir which
breaks number 2. So to fix that, we move the builtins library up one
level into lib/.
The alternative is to turn off per-target dirs, which results in a
builtin file with an arch in the name, then rename and move that file
(since it gets installed into lib/generic/).
So in the end, it's the same amount of hacks. I think it's best to keep
the one that uses LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON, as this is the
recommended way to built these days.
Summary:
When we were first porting to COV5, this lead to some ABI issues due to
a change in how we looked up the work group size. Bitcode libraries
relied on the builtins to emit code, but this was changed between
versions. This prevented the bitcode libraries, like OpenMP or libc,
from being used for both COV4 and COV5. The solution was to have this
'none' functionality which effectively emitted code that branched off of
a global to resolve to either version.
This isn't a great solution because it forced every TU to have this
variable in it. The patch in
https://github.com/llvm/llvm-project/pull/131033 removed support for
COV4 from OpenMP, which was the only consumer of this functionality.
Other users like HIP and OpenCL did not use this because they linked the
ROCm Device Library directly which has its own handling (The name was
borrowed from it after all).
So, now that we don't need to worry about backward compatibility with
COV4, we can remove this special handling. Users can still emit COV4
code, this simply removes the special handling used to make the OpenMP
device runtime bitcode version agnostic.
Most of the dylib functions inside `<__filesystem/operations.h>` are at
the top of the file. There are a few spread out in the file for some
reason, which this patch fixes.
Previously, ranges::min_element delegated to ranges::__min_element_impl, which
duplicated the definition of std::__min_element. This patch updates
ranges::min_element to directly call std::__min_element, which allows
removing the redundant code in ranges::__min_element_impl.
Upon removal of ranges::__min_element_impl, the other ranges algorithms
ranges::{min,max,max_element}, which previously delegated to ranges::__min_element_impl,
have been updated to call std::__min_element instead.
This refactoring unifies the implementation across these algorithms,
ensuring that future optimizations or maintenance work only need to be
applied in one place.
This has multiple benefits:
- There is a single instance of our hash function, reducing object file
size
- The hash implementation isn't instantiated in every TU anymore,
reducing compile times
- Behind an ABI configuration macro it would be possible to salt the
hash
We've started using `_LIBCPP_BEGIN_NAMESPACE_STD` and
`_LIBCPP_END_NAMESPACE_STD` for more than just the namespace for a while
now. For example, we're using it to add visibility annotations to types.
This works very well and avoids a bunch of annotations, but doesn't work
for the few places where we have an unversioned namespace. This adds
`_LIBCPP_BEGIN_UNVERSIONED_NAMESPACE_STD` and
`_LIBCPP_END_UNVERSIONED_NAMESPACE_STD` to make it simpler to add new
annotations consistently across the library as well as making it more
explicit that the unversioned namespace is indeed intended.
Per [range.view]/6, a `view_interface` isn't a base class of itself, so
`enable_view` should report `false`. Also, current implementation
strategy handles `const` but not `volatile`, IIUC cv-qualifiers should
be consistent handled.
In `enable_view.compile.pass.cpp`, coverage for (`const`) `volatile`
types are added.
Drive-by: Remove one unnessary `test_macro.h` inclusion in a test.
Fixes#132577.
The existing using _ForwardLike declaration already fails with a
subsitution failure. The LWG issue was filed to clarify what should
happen for non-referencable types.
Added test to verify libc++ is already enforcing the new Mandates.
Implements:
- LWG3757 What's the effect of std::forward_like<void>(x)
Closes: #105026
In 664f345cd53d1f624d94f9889a1c9fff803e3391, a fix was introduced,
attempting to restore LLVM_DIR and Clang_DIR after doing
find_package(Clang).
However, 6775285e7695f2d45cf455f5d31b2c9fa9362d3d added a return if the
clangTidy target wasn't found. If this is hit, we don't restore LLVM_DIR
and Clang_DIR, which causes strange effects if CMake is rerun a second
time.
Move the code for restoring LLVM_DIR and Clang_DIR to directly after the
find_package calls, to make sure they are restored, regardless of the
find_package outcome.
This isn't the whole team, but enough that one of us will see it and
make sure the right person sees it.
Noted explicitly that Picolibc is also our responsiblity as it's not
always clear that that is tested on Arm.
The PR removes the unnecessary division and modulo operations in the
one-word specialization `__bitset<1, _Size>`. The reason is that for the
one-word specialization, we have `__pos < __bits_per_word` (as
`__bitset<1, _Size>` is an implementation detail only used by the public
`bitset`). So `__pos / __bits_per_word == 0` and `__pos / __pos %
__bits_per_word == __pos`.
The current implementation already have an __initial_descriptor which
saves the initial state. When release() is called, we will reset the
__initial_descriptor.__cur_ pointer.
This patch also updates the status of LWG3120.
Closes#104274
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
1013fe3c0cfd7582e94ef2d4bfd79da7ea1a1289 used to implement LWG2770, but
cb0d4df97490ec2d2b1cdf7574d26b1bc4063599 made LWG2770 unimplemented
again because of CWG2386.
This patch re-implements LWG2770, while keeping the libc++-specific
implementation strategy (which is controversial as noted in LWG4040).
Drive-by:
- Make the test coverage for the controversial part noted in LWG4040
libc++-only.
- Add the previously missed entry for LWG2770 to the documentation.
Previously, const and ref qualification on an operation would cause
__desugars_to to report false, which would lead to unnecessary
pessimizations. The same holds for reference_wrapper.
In practice, const and ref qualifications on the operation itself are
not relevant to determining whether an operation desugars to something
else or not, so can be ignored.
We are not stripping volatile qualifiers from operations in this patch
because we feel that this requires additional discussion.
Fixes#129312
The comment seems to be wrong by now. The only difference this makes for
GCC is that there are fewer private symbols exported from the dylib,
which can't ever be accessed by user code anyways.
That header is generated via CMake, but it is nonetheless present in the
final installation, so it should be covered by the modulemap.
rdar://131418726
The `__is_referenceable` builtin has been removed from Clang, since all
its uses have been replaced by builtins themselves. This trait only
exists for GCC compatibility and to word around some issues in the other
traits. The non-builtin implementation has been refactored to use
variable templates instead, making the implementation much simpler.
We'e specialized `std::signbit` for signed and unsigned integral types
seperately, even though the optimizer can trivially figure out that
`unsigned_value < 0` always false is. This patch removes the
specialization, since there is really not much of a benefit to it.
And use it for test cases that became constant-evaluation-suitable due
to P2562R1.
`TEST_STD_AT_LEAST_(20|23)_OR_RUNTIME_EVALUATED` are the precedents.
* Fix copy-paste damage in `formatter.tai_time.pass.cpp`.
+ Comparing the `#if` to the `#else` case, it's clear that this
half-copied check should be removed.
* Mark `is_steady` as `[[maybe_unused]]`.
+ It's only used within `LIBCPP_STATIC_ASSERT`.
As discussed during the last monthly meeting we want to be able to test
the GCC development version in our CI, but we don't want to commit to
support this compiler version.
This adds the image to the CI Docker image. At the moment GCC-15 will
not pass the CI. Having it in the Docker image makes it possible to
validate fixes.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Co-authored-by: Hristo Hristov <hghristov.rmm@gmail.com>
For certain time_points there are specializations of __convert_to_tm.
This means the non-specialized version is never called. This means some
of the `if constexpr` will never be true. These are removed.
Since there is a `static_assert` accidental removal of the
specialization will make the code ill-formed.
In recent versions of Clang, using -std=c++20 (and later) implies LSV
when compiling with modules. This change resulted in making our LSV job
redundant with the regular modules job, which uses the latest Standard.
This patch increases the coverage of our CI without increasing its cost
by pinning the LSV job to use C++17, which normally doesn't use LSV. A
related question is whether we should add coverage for non-LSV builds
using Clang modules.
The current tests for `vector<bool>` fail to adequately cover realistic
scenarios, as they are limited to cases of up to 3 bytes, representing
less than 1/2 of a word size on a 64-bit system. However, most
`vector<bool>` operations rely on code paths triggered only when
handling multiple storage words (8 bytes each). To address this gap,
this PR rewrites the tests for copy and move constructors, as well as
allocator-extended copy and move constructors, ensuring that previously
untested code paths are now thoroughly validated.
* libcxx/test/support/min_allocator.h
+ Fix `tiny_size_allocator::rebind` which mistakenly said `T` instead of
`U`.
*
libcxx/test/std/algorithms/alg.modifying.operations/alg.partitions/stable_partition.pass.cpp
+ `std::stable_partition` requires bidirectional iterators.
* libcxx/test/std/containers/sequences/vector.bool/max_size.pass.cpp
+ Fix allocator type given to `std::vector<bool>`. The element types are
required to match, [N5008](https://isocpp.org/files/papers/N5008.pdf)
\[container.alloc.reqmts\]/5: "*Mandates:* `allocator_type::value_type`
is the same as `X::value_type`."
* libcxx/test/std/time/time.clock/time.clock.utc/types.compile.pass.cpp
+ Mark `is_steady` as `[[maybe_unused]]`, as it appears within
`LIBCPP_STATIC_ASSERT` only.
*
libcxx/test/std/algorithms/alg.modifying.operations/alg.rotate/rotate.pass.cpp
*
libcxx/test/std/algorithms/alg.modifying.operations/alg.swap/swap_ranges.pass.cpp
* libcxx/test/std/utilities/utility/utility.swap/swap_array.pass.cpp
+ Fix MSVC warning C4127 "conditional expression is constant".
`TEST_STD_AT_LEAST_23_OR_RUNTIME_EVALUATED` was introduced for this
purpose, so it should be used consistently.
* libcxx/test/std/numerics/numeric.ops/numeric.ops.gcd/gcd.pass.cpp
+ Fix `gcd()` precondition violation for `signed char`. This test case
was causing `-128` to be passed as a `signed char` to `gcd()`, which is
forbidden.
* libcxx/test/std/containers/sequences/array/assert.iterators.pass.cpp
*
libcxx/test/std/containers/sequences/vector/vector.modifiers/assert.push_back.invalidation.pass.cpp
*
libcxx/test/std/input.output/iostream.format/print.fun/no_file_description.pass.cpp
+ Split some REQUIRES and XFAIL lines. This is a "nice to have" for
MSVC's internal test harness, which is extremely simple and looks for
exact comment matches to skip tests. We can recognize the specific lines
"REQUIRES: has-unix-headers" and "XFAIL: msvc", but it's a headache to
maintain if they're chained with other conditions.
* libcxx/test/support/sized_allocator.h
+ Fix x86 truncation warnings. `std::allocator` takes `std::size_t`, so
we need to `static_cast`.
*
libcxx/test/std/input.output/file.streams/fstreams/ifstream.members/offset_range.pass.cpp
+ Fix x86 truncation warning. `std::min()` is returning
`std::streamoff`, which was being unnecessarily narrowed to
`std::size_t`.
*
libcxx/test/std/algorithms/alg.sorting/alg.merge/inplace_merge_comp.pass.cpp
+ Fix MSVC warning C4127 "conditional expression is constant" for an
always-true branch. This was very recently introduced by #129008 making
`N` constexpr. As it's a local constant just nine lines above, we don't
need to test whether 100 is greater than 0.
Drive-by changes:
- Consistently mark `std::__inplace_merge::__inplace_merge_impl`
`_LIBCPP_CONSTEXPR_SINCE_CXX26`.
- This function template is only called by other functions that becomes
constexpr since C++26, and it itself calls `std::__inplace_merge` that
is constexpr since C++26.
- Unblock related test coverage in constant evaluation for
`stable_partition`, `ranges::stable_sort`, `std::stable_sort`,
`std::stable_partition`, and `std::inplace_merge`.
https://wg21.link/LWG3088 requires that `forward_list::merge()` is a no-op when passed
`*this`, which aligns with the behavior of `list::merge`. Although libc++'s implementation
of `forward_list::merge()` already meets this requirement, there were no tests to verify
this behavior. This patch adds the necessary tests to ensure that self-merging remains a
no-op and prevents any future regressions on this.
Closes#104942.
When an allocator-aware container already defines a member type alias
`__alloc_traits` for `std::allocator_traits<allocator_type>`, we should
consistently use `__alloc_traits`. Mixing the usage of both
`__alloc_traits` and `std::allocator_traits` can lead to inconsistencies
and confusion.
The existing tests for `vector<bool>` copy- and move-assignment
operators are limited to 3 bits only, which are inadequate to cover
realistic scenarios. Most `vector<bool>` operations have code paths that
are executed only when multiple storage words are involved, with each
storage word typically comprising 64 bits on a 64-bit platform.
Furthermore, the existing tests fail to cover all combinations
`POCCA`/`POCMA`, along with different allocator equality and/or
reallocation scenarios, leaving some critical code paths untested.
This patch enhances the test coverage by introducing new tests covering
up to 5 storage words, ensuring that partial words in the front or tail,
and whole words in the middle are all properly tested. Moreover, these
new tests ensure that the copy- and move-assignment operators are tested
under all combinations of `POCCA`/`POCMA` and various allocator equality
scenarios, both with or without reallocations.
This patch fixes an issue in libc++ where `std::copy_backward` and
`ranges::copy_backward` incorrectly copy `std::vector<bool>` with small
storage types (e.g., `uint8_t`, `uint16_t`). The problem arises from
flawed bit mask computations involving integral promotions and sign-bit
extension, leading to unintended zeroing of bits. This patch corrects
the bitwise operations to ensure correct bit-level copying.
Fixes#131718.
The current implementation of `{std, ranges}::copy` fails to copy
`vector<bool>` correctly when the underlying storage type
(`__storage_type`) is smaller than `int`, such as `unsigned char`,
`unsigned short`, `uint8_t` and `uint16_t`. The root cause is that the
unsigned small storage type undergoes integer promotion to (signed)
`int`, which is then left and right shifted, leading to UB (before
C++20) and sign-bit extension (since C++20) respectively. As a result,
the underlying bit mask evaluations become incorrect, causing erroneous
copying behavior.
This patch resolves the issue by correcting the internal bitwise
operations, ensuring that `{std, ranges}::copy` operates correctly for
`vector<bool>` with any custom (unsigned) storage types.
Fixes#131692.
The current implementation of `{std, ranges}::equal` fails to correctly
compare `vector<bool>`s when the underlying storage type is smaller than
`int` (e.g., `unsigned char`, `unsigned short`, `uint8_t` and
`uint16_t`). See [demo](https://godbolt.org/z/j4s87s6b3)). The problem
arises due to integral promotions on the intermediate bitwise
operations, leading to incorrect final equality comparison results. This
patch fixes the issue by ensuring that `{std, ranges}::equal` operate
properly for both aligned and unaligned bits.
Fixes#126369.
