This PR implements a generic backend-agnostic parallel `std::is_sorted`
based on `std::transform_reduce`.
While this approach is suboptimal comparing a direct backend-specific
implementation, since it doesn't support early termination and requires
a reduction operation, it does show speedup when the dataset is large
enough and the comparator is not absolutely trivial.
Parent issue: #99938
Until C++20, `std::find_if(_not)` were not `constexpr`, so uses of
`TEST_CONSTEXPR_CXX17` make the test functions ill-formed, no diagnostic
required in C++17 mode.
The uses were introduced in 2b4b26ea84fd9c95d0ff25ce338c15ea5e74a4e4,
while the transformation looked incorrect - `TEST_CONSTEXPR_CXX20`
should be used instead.
Drive-by changes: Fix comments in both changed test files to match the
actually standardized wording.
#175913 removed that `__builtin_assume_dereferenceable(ptr, 0)` implies
`ptr != nullptr`, which should allow us to use the builtin with LLVM 23.
This reverts commit 776c09c212e945fdceeae240b42c38df3dd34727.
This implements all of [P2404R3](https://wg21.link/p2404r3)'s concept
changes.
---------
Co-authored-by: A. Jiang <de34@live.cn>
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Currently, the version of `ranges::for_each` which takes whole
associative containers treats `__root->__get_value()` as an existing
element even when the container is empty.
We should exit earlier in `__specialized_algorithm<...>::operator()`
when the tree is empty.
#164405 added specializations of `for_each` that didn't do the ranges
call shenanigans, but instead just did what the classic algorithms have
to do. This updates the calls to work for the ranges overloads as well.
This allows propagating optimizations to different algorithms by just
optimizing the lowest one. This is especially relevant now that we start
optimizing how we're iterating through ranges (e.g. the segmented
iterator optimizations) and adding assumptions so the compier can better
leverage semantics guaranteed by the standard (e.g.
`__builtin_assume_dereferenceable`).
This should improve the time it takes to run the test suite a bit. Right
now there are only a handful of headers in the modulemap because we're
missing a lot of includes in the tests. New headers should be added
there from the start, and we should fill up the modulemap over time
until it contains all the test support headers.
Part of #102817.
This patch attempts to optimize the performance of `std::generate` for
segmented iterators. Below are the benchmark numbers from
`libcxx\test\benchmarks\algorithms\modifying\generate.bench.cpp`. Test
cases that use segmented iterators have also been added.
- before
```
std::generate(deque<int>)/32 194 ns 193 ns 3733333
std::generate(deque<int>)/50 276 ns 276 ns 2488889
std::generate(deque<int>)/1024 5096 ns 5022 ns 112000
std::generate(deque<int>)/8192 40806 ns 40806 ns 17231
```
- after
```
std::generate(deque<int>)/32 106 ns 105 ns 6400000
std::generate(deque<int>)/50 139 ns 138 ns 4977778
std::generate(deque<int>)/1024 2713 ns 2699 ns 248889
std::generate(deque<int>)/8192 18983 ns 19252 ns 37333
```
---------
Co-authored-by: A. Jiang <de34@live.cn>
The outer iterator needs to move to the next segment when calling
__compose.
Without this change, `find_segment_if` would never reach the end of the
join_view which caused erroneous result when calling `ranges::find` on a
join_view of bidirectional ranges.
Other specializations using the segmented iterator trait were likely to
be affected as well.
Fixes#158279Fixes#93180
The complexity is "at most N swaps" _for each invocation of `rotate`_,
but the tests currently assert that the total number of swaps for N
calls is at most N. The standard allows that to be N squared, so the
test is either requiring more than the standard (and the comment in the
test) promises, or somebody just forgot to reset the counter on each
iteration.
We've built up quite a few links directly to github within the code
base. We should instead use `llvm.org/PR<issue-number>` to link to bugs,
since that is resilient to the bug tracker changing in the future. This
is especially relevant for tests linking to bugs, since they will
probably be there for decades to come. A nice side effect is that these
links are significantly shorter than the GH links, making them much less
of an eyesore.
This patch also replaces a few links that linked to the old bugzilla
instance on llvm.org.
I noticed a typo in the directory name `refwrap.comparissons`, then did
a quick pass to fix typos elsewhere in the tests.
All fixes were manual (some carefully search-and-replaced); I used
[cspell](https://www.npmjs.com/package/cspell) to find them.
Previously, the segmented iterator optimization was limited to `std::{for_each, for_each_n}`. This patch
extends the optimization to `std::ranges::for_each` and `std::ranges::for_each_n`, ensuring consistent
optimizations across these algorithms. This patch first generalizes the `std` algorithms by introducing
a `Projection` parameter, which is set to `__identity` for the `std` algorithms. Then we let the `ranges`
algorithms to directly call their `std` counterparts with a general `__proj` argument. Benchmarks
demonstrate performance improvements of up to 21.4x for ``std::deque::iterator`` and 22.3x for
``join_view`` of ``vector<vector<char>>``.
Addresses a subtask of #102817.
This patch enhances the performance of `std::for_each_n` when used with
segmented iterators, leading to significant performance improvements,
summarized in the tables below. This addresses a subtask of
https://github.com/llvm/llvm-project/issues/102817.
charN_t represent code units of different UTF encodings. Therefore the
values of 2 different charN_t objects do not represent the same
characters.
In order to avoid comparing apples and oranges, we add new warnings to
warn on:
- Implicit conversions
- Comparisons
- Other cases involving arithmetic conversions
We only produce the warning if we cannot establish the comparison would
be safe through constant evaluation.
The new `-Wimplicit-unicode-conversion` warning is enabled by default.
Note that this PR intentionally doesn;t touches char/wchar_t, but it
would be worth considering also warning on extending the new warnings to
these types (in a follow up)
Additionally most arithmetic operations on charN_t don't really make
sense (ie what does it mean to addition code units), so we could add
warnings for that.
Fixes#138526
This patch enhances the test coverage of `{std,ranges}::swap_ranges` by
adding larger test cases with 100 elements across different containers.
It also inlines standalone tests for better readability, avoiding
unnecessary navigation.
This patch addresses a follow-up suggestion from PR #121138 to extend
test coverage beyond 3 elements.
As libc++ has been implementing niebloids as CPOs since LLVM 14 due to
https://reviews.llvm.org/D116570.
Also changes some comments in test files to use the formal term
"algorithm function object".
Closes#118133.
This patch enhances test readability by inlining standalone tests,
eliminating unnecessary navigation. Additionally, several classes with
ad-hoc names have been renamed for better clarity:
- `A` -> `CharWrapper` as it wraps a char
- `B -> CharTransformer` as it accepts a char `xc` but stores `xc + 1`
- `Storage -> CharUnionStorage` as it stores a union of 2 `char`s.
This patch addresses a follow-up comment from #120909 to inline tests.
# Overview
As a disclaimer, this is my first PR to LLVM and while I've tried to
ensure I've followed the LLVM and libc++ contributing guidelines,
there's probably a good chance I missed something. If I have, just let
me know and I'll try to correct it as soon as I can.
This PR implements `std::ranges::iota` and
`std::ranges::out_value_result` outlined in
[P2440r1](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2440r1.html).
As outlined in the paper above, I've:
- Implemented `out_value_result` and added to `<algorithm>`
- Added `out_value_result`, `iota_result`, and two overloads of `iota`
to `std::ranges` in `<numeric>`
- Updated the version macro `__cpp_lib_ranges_iota` in `<version>`
I've also added tests for `ranges::iota` and `ranges::out_value_result`.
Lastly, I added those structs to the appropriate module files.
Partially implements #105184
EDIT: Forgot to mention in the original post, thanks to @hawkinsw for
taking a look at a preliminary version of this PR!
# TODOs
- [x] Updating the range [status
doc](https://github.com/jamesETsmith/llvm-project/blob/main/libcxx/docs/Status/RangesMajorFeatures.csv)
- [x] Ensure all comments from https://reviews.llvm.org/D121436 are
addressed here
- [X] EDIT (I'll do this in a separate PR). ~~I'm open to implementing
the rest of P2440r1 (`ranges::shift_left` and `ranges::shift_right`) if
that's ok, I just wanted to get feedback on `ranges::iota` first~~
- [x] I've been having trouble building the modules locally and want to
make sure that's working properly
Closes: #134060
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.
* 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`.
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.
This PR fixes an ambiguous call encountered while using the
`std::ranges::count` and `std::count` algorithms with `vector<bool>`
with small `size_type`s.
The ambiguity arises from integral promotions during the internal
bitwise arithmetic of the `count` algorithms for small integral types.
This results in multiple viable candidates:
`__libcpp_popcount(unsigned)`,` __libcpp_popcount(unsigned long)`, and
`__libcpp_popcount(unsigned long long)`, leading to an ambiguous call
error. To resolve this ambiguity, we introduce a dispatcher function,
`__popcount`, which directs calls to the appropriate overloads of
`__libcpp_popcount`. This closes#122528.
This PR fixes an ambiguous call encountered when using the `std::ranges::find` or `std::find`
algorithms with `vector<bool>` with small `allocator_traits::size_type`s, an issue reported
in #122528. The ambiguity arises from integral promotions during the internal bitwise
arithmetic of the `find` algorithms when applied to `vector<bool>` with small integral
`size_type`s. This leads to multiple viable candidates for small integral types:
__libcpp_ctz(unsigned), __libcpp_ctz(unsigned long), and __libcpp_ctz(unsigned long long),
none of which represent a single best viable match, resulting in an ambiguous call error.
To resolve this, we propose invoking an internal function __countr_zero as a dispatcher
that directs the call to the appropriate overload of __libcpp_ctz. Necessary amendments
have also been made to __countr_zero.
This PR optimizes the performance of `std::ranges::rotate` for
`vector<bool>::iterator`. The optimization yields a performance
improvement of up to 2096x.
Closes#64038.
Drive-by: Enables test coverage for `ranges::stable_sort` with proxy
iterators, and changes "constexpr in" to "constexpr since" in comments
in `<algorithm>`.
This PR optimizes the performance of `std::ranges::swap_ranges` for
`vector<bool>::iterator`, addressing a subtask outlined in issue #64038.
The optimizations yield performance improvements of up to **611x** for
aligned range swap and **78x** for unaligned range swap comparison.
Additionally, comprehensive tests covering up to 4 storage words (256
bytes) with odd and even bit sizes are provided, which validate the
proposed optimizations in this patch.
Drive-by changes:
- Enables no-memory case for Clang.
- Enables `robust_re_difference_type.compile.pass.cpp` and
`robust_against_proxy_iterators_lifetime_bugs.pass.cpp` test coverage
for `std::stable_sort` in constant evaluation since C++26. The changes
were missing in the PR making `std::stable_sort` `constexpr`.
This PR optimizes the performance of `std::ranges::equal` for
`vector<bool>::iterator`, addressing a subtask outlined in issue #64038.
The optimizations yield performance improvements of up to 188x for
aligned equality comparison and 82x for unaligned equality
comparison. Moreover, comprehensive tests covering up to 4 storage words
(256 bytes) with odd and even bit sizes are provided, which validate the
proposed optimizations in this patch.
This PR refactors the tests and fix some problems:
- Refactor similar tests using `types::for_each` to remove redundant code;
- Explicitly include the missing header `type_algorithms.h` instead of relying
on a transitive include;
- Fix the incorrect constexpr declaration in `rotate.pass.cpp`, where
the `test()` function is incorrectly defined as `TEST_CONSTEXPR_CXX17`,
which is wrong since `std::rotate()` becomes constexpr only since C++20.
libc++ currently has very limited test coverage for `std::ranges{fill, fill_n, find}`
with `vector<bool>::iterator` optimizations. Specifically, the existing tests for
`std::ranges::fill` only covers cases of 1 - 2 bytes, which is merely 1/8 to 1/4
of the `__storage_type` word size. This renders the tests insufficient to validate
functionality for whole words, with or without partial words (which necessitates at
least 8 bytes of data). Moreover, no tests were provided for `ranges::{find, fill_n}`
with `vector<bool>::iterator` optimizations. This PR fills in the gap.
