Re: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]
Mark Millard writes: > Alexey Dokuchaev wrote on > Date: Wed, 03 May 2023 07:53:09 UTC : > >> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >> > ... >> > There is no feasible way we are going to make the branch point of >> > stable/14 in time, with that scheduled for May 12, 2023 with the above >> > points. That said, this is not an all-inclusive list, but the more >> > major items on our radar at the moment. >> >> Does this delay mean we might get Clang 16 in the base? Current 15.0.7 >> hits assertion on one of my ports which had allegedly been fixed in 16. >> Also, AFAIU it comes with better support for modern C++, e.g. ranges. > > These notes are based on using -std=c++20 and llvm16 on > opensuse tumblweed (in early April), which has libc++ > support configurable. They also presume that the FreeBSD > llvm16 update fully adopts the libc++ from llvm16. > (FreeBSD LLVM upgrades do not always do so at the initial > upgrade time.) FWIW, std::ranges in base libc++ 16 (via llvm-16-update branch) works fine at least in emulators/yuzu (c++20) and x11-wm/hyprland (c++23). More can take advantage but currently use a workaround e.g., $ rg -l :devel/range-v3 | sed s,/Makefile,, biology/seqan3 devel/fbthrift editors/imhex lang/solidity net-im/telegram-desktop
Re: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]
On May 3, 2023, at 08:57, Mark Millard wrote: > Alexey Dokuchaev wrote on > Date: Wed, 03 May 2023 07:53:09 UTC : > >> On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >>> ... >>> There is no feasible way we are going to make the branch point of >>> stable/14 in time, with that scheduled for May 12, 2023 with the above >>> points. That said, this is not an all-inclusive list, but the more >>> major items on our radar at the moment. >> >> Does this delay mean we might get Clang 16 in the base? Current 15.0.7 >> hits assertion on one of my ports which had allegedly been fixed in 16. >> Also, AFAIU it comes with better support for modern C++, e.g. ranges. > > These notes are based on using -std=c++20 and llvm16 on > opensuse tumblweed (in early April), which has libc++ > support configurable. They also presume that the FreeBSD > llvm16 update fully adopts the libc++ from llvm16. > (FreeBSD LLVM upgrades do not always do so at the initial > upgrade time.) > > __cpp_lib_ranges would go from undefined to 202106 . > C++20 also has a later 202110 . C++23 has 3 later values, > the last being 202211 . (I'm generally omitting the L > suffixes in my materials.) > > A couple of the C++20 ranges versions are late, > retroactive fixes ["(DR)"s] for things that > could not wait for C++23: > > __cpp_lib_ranges -- 202106 (C++20) (DR) > __cpp_lib_ranges -- 202110 (C++20) (DR) > > So only the 202106 one was in llvm16 when I tested > llvm16. (If I remember right, using -std=c++23 got > the 202110 fix as well.) > > Other libc++ things going from undefined to a defined > status are: > > __cpp_lib_constexpr_complex > __cpp_lib_constexpr_vector > __cpp_lib_memory_resource > __cpp_lib_polymorphic_allocator > __cpp_lib_source_location > > It does not appear that any other __cpp_lib_... macros > would change values for -std=c+=20 use. Typo fix to the above: -std=c++20 > As for the overall status for ranges . . . > > C++23 has lots of changes/additions for ranges: > (The --'s indicate being undefined in llvm15.) I should have noted that the MM months below are from/for the standard and are not indications of llvm16 or later of having implemented them for -std=c+=23 . > __cpp_lib_ranges -- 202202 (C++23) > __cpp_lib_ranges -- 202207 (C++23) > __cpp_lib_ranges -- 202211 (C++23) > __cpp_lib_ranges_as_const -- 202207 (C++23) > __cpp_lib_ranges_as_rvalue -- 202207 (C++23) > __cpp_lib_ranges_cartesian_product -- 202207 (C++23) > __cpp_lib_ranges_chunk -- 202202 (C++23) > __cpp_lib_ranges_chunk_by -- 202202 (C++23) > __cpp_lib_ranges_contains -- 202207 (C++23) > __cpp_lib_ranges_enumerate -- 202303 (C++23) > __cpp_lib_ranges_fold -- 202207 (C++23) > __cpp_lib_ranges_iota -- 202202 (C++23) > __cpp_lib_ranges_join_with -- 202202 (C++23) > __cpp_lib_ranges_repeat -- 202207 (C++23) > __cpp_lib_ranges_slide -- 202202 (C++23) > __cpp_lib_ranges_starts_ends_with -- 202106 (C++23) > __cpp_lib_ranges_stride -- 202207 (C++23) > __cpp_lib_ranges_to_container -- 202202 (C++23) > __cpp_lib_ranges_zip -- 202110 (C++23) > > Ranges seems to be an active area of development > across multiple standard vintages. === Mark Millard marklmi at yahoo.com
What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items]
Alexey Dokuchaev wrote on Date: Wed, 03 May 2023 07:53:09 UTC : > On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: > > ... > > There is no feasible way we are going to make the branch point of > > stable/14 in time, with that scheduled for May 12, 2023 with the above > > points. That said, this is not an all-inclusive list, but the more > > major items on our radar at the moment. > > Does this delay mean we might get Clang 16 in the base? Current 15.0.7 > hits assertion on one of my ports which had allegedly been fixed in 16. > Also, AFAIU it comes with better support for modern C++, e.g. ranges. These notes are based on using -std=c++20 and llvm16 on opensuse tumblweed (in early April), which has libc++ support configurable. They also presume that the FreeBSD llvm16 update fully adopts the libc++ from llvm16. (FreeBSD LLVM upgrades do not always do so at the initial upgrade time.) __cpp_lib_ranges would go from undefined to 202106 . C++20 also has a later 202110 . C++23 has 3 later values, the last being 202211 . (I'm generally omitting the L suffixes in my materials.) A couple of the C++20 ranges versions are late, retroactive fixes ["(DR)"s] for things that could not wait for C++23: __cpp_lib_ranges -- 202106 (C++20) (DR) __cpp_lib_ranges -- 202110 (C++20) (DR) So only the 202106 one was in llvm16 when I tested llvm16. (If I remember right, using -std=c++23 got the 202110 fix as well.) Other libc++ things going from undefined to a defined status are: __cpp_lib_constexpr_complex __cpp_lib_constexpr_vector __cpp_lib_memory_resource __cpp_lib_polymorphic_allocator __cpp_lib_source_location It does not appear that any other __cpp_lib_... macros would change values for -std=c+=20 use. As for the overall status for ranges . . . C++23 has lots of changes/additions for ranges: (The --'s indicate being undefined in llvm15.) __cpp_lib_ranges -- 202202 (C++23) __cpp_lib_ranges -- 202207 (C++23) __cpp_lib_ranges -- 202211 (C++23) __cpp_lib_ranges_as_const -- 202207 (C++23) __cpp_lib_ranges_as_rvalue -- 202207 (C++23) __cpp_lib_ranges_cartesian_product -- 202207 (C++23) __cpp_lib_ranges_chunk -- 202202 (C++23) __cpp_lib_ranges_chunk_by -- 202202 (C++23) __cpp_lib_ranges_contains -- 202207 (C++23) __cpp_lib_ranges_enumerate -- 202303 (C++23) __cpp_lib_ranges_fold -- 202207 (C++23) __cpp_lib_ranges_iota -- 202202 (C++23) __cpp_lib_ranges_join_with -- 202202 (C++23) __cpp_lib_ranges_repeat -- 202207 (C++23) __cpp_lib_ranges_slide -- 202202 (C++23) __cpp_lib_ranges_starts_ends_with -- 202106 (C++23) __cpp_lib_ranges_stride -- 202207 (C++23) __cpp_lib_ranges_to_container -- 202202 (C++23) __cpp_lib_ranges_zip -- 202110 (C++23) Ranges seems to be an active area of development across multiple standard vintages. === Mark Millard marklmi at yahoo.com
