-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[libc++] Ambiguous call encountered in {ranges, std}::{count, find} algorithms #122528
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
libc++
libc++ C++ Standard Library. Not GNU libstdc++. Not libc++abi.
Comments
This was referenced Jan 13, 2025
ldionne
pushed a commit
that referenced
this issue
Mar 13, 2025
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.
frederik-h
pushed a commit
to frederik-h/llvm-project
that referenced
this issue
Mar 18, 2025
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 llvm#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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
When using
vector<bool>
with a custom-sized allocator, thestd::ranges::count
andstd::count
algorithms encounter an ambiguous call to the internal function__libcpp_popcount
, and thestd::ranges::find
andstd::find
algorithms encounter a similar ambiguous call to the internal function__libcpp_ctz
, as demonstrated below.Note: This issue first came up while working on #119801.
Godbolt link
The error message from clang is:
Analysis
When used with
sized_allocator
with smaller integral types, the internal bitwise arithmetic incount.h
exhibits integral promotions, yielding anint
result. This results in no single best viable function among the viable set with (__libcpp_popcount(unsigned)
,__libcpp_popcount(unsigned long)
, and__libcpp_popcount(unsigned long long)
), causing an ambiguous call error. Similarly, an integral promotion occurs in the internal bitwise logic offind.h
, resulting in no single best viable function among three overloads of__libcpp_ctz
.Proposed Solution
Provide a function template that dispatches the call to the appropriate
__libcpp_popcount
(forcount.h
) or__libcpp_ctz
(forfind.h
) based on the size of the integral types:unsigned short
,uint8_t
,uint16_t
, etc), dispatch the call to__libcpp_popcount(unsigned)
or__libcpp_ctz(unsigned)
.__libcpp_popcount(unsigned long)
or__libcpp_popcount(unsigned long long)
forcount.h
according to thesizeof(type)
values. Similarly, dispatch the call to the rest__libcpp_ctz
overloads forfind.h
.The text was updated successfully, but these errors were encountered: