Date: Wed, 3 May 2023 08:57:08 -0700 From: Mark Millard <marklmi@yahoo.com> To: danfe@freebsd.org, Current FreeBSD <freebsd-current@freebsd.org> Subject: What llvm16 libc++ updates for -std=c++20 use [was: Re: Delay in 14.0-RELEASE cycle and blocking items] Message-ID: <DED8BE5C-DBCF-4762-853F-CB5F49FA25E2@yahoo.com> References: <DED8BE5C-DBCF-4762-853F-CB5F49FA25E2.ref@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexey Dokuchaev <danfe_at_freebsd.org> wrote on Date: Wed, 03 May 2023 07:53:09 UTC : > On Mon, May 01, 2023 at 06:14:49PM +0000, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?DED8BE5C-DBCF-4762-853F-CB5F49FA25E2>