amazonlinux
[Bug] - clang++ 15.0.7 in C++20 mode with stdlibc++ 14 fails with <chrono> on AL 2023.7.20250331
Using clang++ and including <chrono> on AL 2023.7.20250331 in C++20 mode breaks the iterator implementation in libstdc++ 14.
To Reproduce This code
#include <chrono>
int main()
{
return 0;
}
when being compiled with clang++ -std=c++20 test.cpp -o test results in several pages of template errors, with these first lines:
In file included from test.cpp:1:
In file included from /usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/chrono:45:
In file included from /usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/sstream:40:
In file included from /usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/istream:40:
In file included from /usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/ios:42:
In file included from /usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/char_traits.h:57:
In file included from /usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/stl_construct.h:61:
In file included from /usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/stl_iterator_base_types.h:71:
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/iterator_concepts.h:1037:13: error: no matching function for call to '__begin'
= decltype(ranges::__access::__begin(std::declval<_Tp&>()));
^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/ranges_base.h:511:5: note: in instantiation of template type alias '__range_iter_t' requested here
using iterator_t = std::__detail::__range_iter_t<_Tp>;
^
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/ranges_util.h:132:36: note: in instantiation of template type alias 'iterator_t' requested here
requires contiguous_iterator<iterator_t<_Derived>>
^
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/ranges_util.h:262:29: note: in instantiation of template class 'std::ranges::view_interface<std::ranges::subrange<const wchar_t *, const wchar_t *, std::ranges::subrange_kind::sized>>' requested here
class subrange : public view_interface<subrange<_It, _Sent, _Kind>>
^
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/iterator_concepts.h:1003:22: note: in instantiation of template class 'std::ranges::subrange<const wchar_t *, const wchar_t *, std::ranges::subrange_kind::sized>' requested here
{ __decay_copy(__t.begin()) } -> input_or_output_iterator;
^
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/iterator_concepts.h:1003:6: note: in instantiation of requirement here
{ __decay_copy(__t.begin()) } -> input_or_output_iterator;
^~~~~~~~~~~~~~~~~~~~~~~~~
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/iterator_concepts.h:1001:32: note: (skipping 11 contexts in backtrace; use -ftemplate-backtrace-limit=0 to see all)
concept __member_begin = requires(_Tp& __t)
^
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/bits/unicode.h:591:5: note: while checking constraint satisfaction for template '_Utf_view<char32_t, std::ranges::subrange<const wchar_t *, const wchar_t *, std::ranges::subrange_kind::sized>>' required here
using _Utf32_view = _Utf_view<char32_t, _View>;
^~~~~
/usr/bin/../lib/gcc/aarch64-amazon-linux/14/../../../../include/c++/14/format:439:3: note: in instantiation of template type alias '_Utf32_view' requested here
_Utf32_view<ranges::subrange<iterator>> __uv({__first, __last});
^
It compiles fine with gcc14-g++ -std=c++20 test.cpp -o test.
Expected behavior No error.
Note
This ticket was initially about including the <format> header, but I demonstrate this now with including the <chrono> header - as that one existed long before C++20.
This is a known clang 15 bug. We will be releasing an updated clang 15 shortly which goes back to using gcc 11 headers instead as a workaround. In parallel we are working on two more toolchain improvements:
-
gcc 11 will be using it's own version of libstdc++ (and runtime libs) for linking. Programs will still use the updated libstdc++ 14 at runtime but will be linking against the version from 11. This avoids a (rare) mismatch between gcc 11 headers and libstdc++ implementation when chosing symbol versions at linking time. The unfortunate side effect is that C++ objects (libraries) built with gcc 14 will usually fail to link when used in a program built with gcc 11, but you can't win this game.
-
we will be releasing namespaced llvm18/clang18/lld18 (and newer versions to follow)
