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
Boot failure on a ThinkPad T14/Ryzen 7 Pro 6850U
Hello all! I confess that this issue exists on 13.1 and 13.2 in addition to the 14-CURRENT snapshot from last week but hopefully there is more to try. This Pr covers the fundamental issue and I have been updating it a I try suggestions: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270707 In short, stock kernels, non-verbose stop at: ... psm0: model Generic PS/2 mouse, device ID 0 battery0: on acpi0 acpi_acad0: on acpi0 A verbose boot stops at: ... pcib0: allocated type 4 (0x3f8-0x3f8) for rid 0 of uart0 uart0 failed to probe at port 0x3f8 irq 4 on isa0 pcib0: allocated type 4 (0x2f8-0x2f8) for rid 0 of uart1 A kernel built with options ACPI_DEBUG with these boot parameters: set debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS" set debug.acpi.level="ACPI_LV_ALL_EXCEPTIONS" Stops at: ... exregion-059 ExSystemMemorySpaceHan: System-Memory (width 8) R/W 0 Address=70F3 ... nsxfeval-0386 EvaluateObject : Null handle with relative pathname [_PRW] nsxfeval-0386 EvaluateObject... Related suggestion: Should 'options ACPI_DEBUG' be built into the snapshot kernels along with WITNESS etc? Any additional suggestions? Thank you! Michael
Re: Delay in 14.0-RELEASE cycle and blocking items
> Am 03.05.2023 um 18:27 schrieb Glen Barber : > > On Wed, May 03, 2023 at 07:53:09AM +, Alexey Dokuchaev wrote: >> 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? >> > > Well, the delay really means we do not currently have OpenSSL 3 in base. > > Glen > I cannot help with this, of course. But out of interest: what are the problems? There was a post on the haproxy mailing-list a while back, linking to some github issue and from what I understood, there are huge performance-problems in there. Rainer
Re: Delay in 14.0-RELEASE cycle and blocking items
On Wed, May 03, 2023 at 07:53:09AM +, Alexey Dokuchaev wrote: > 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? > Well, the delay really means we do not currently have OpenSSL 3 in base. Glen signature.asc Description: PGP signature
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
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-03 10:59, schrieb Mina Galić: Is there a chance to get pkgbase into 14.0? If not it will take another X years to have it in 15.0... PkgBase *is* in 14, like it is in 13. The question is just if re@ has the resources (people, time, Hardware) to provide a Repository. Mina Galić Fingers crossed that the resources are available!
Re: Delay in 14.0-RELEASE cycle and blocking items
> Is there a chance to get pkgbase into 14.0? If not it will take another X > years to have it in 15.0... PkgBase *is* in 14, like it is in 13. The question is just if re@ has the resources (people, time, Hardware) to provide a Repository. Mina Galić
Re: Delay in 14.0-RELEASE cycle and blocking items
Am 2023-05-01 20:14, schrieb Glen Barber: According to the 14.0-RELEASE schedule, the code slush in main and the freeze to the KBI for 14.0 was scheduled for April 25, 2023. As some of you may have noticed, that did not happen. First, and most importantly for 14.0, is the status of the OpenSSL update to version 3. This in itself is reason to delay the schedule until some tangible progress has been made. Yes, some have expressed interest in helping in this area, however at this moment, this is the key blocker. Second is the status of the branch and how it pertains to the recent upstream merge from OpenZFS. Although block_cloning is disabled by default, there have been other regressions discovered (and fixed), but as a whole, I do not feel that we have a solid understanding of the regressions about which we do not know. 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. A more up-to-date schedule for the 14.0 release will be published in the near future, though nothing is yet set in stone. Thank you for your patience, and for any help in getting us through these outstanding items. Glen On behalf of: re@ Is there a chance to get pkgbase into 14.0? If not it will take another X years to have it in 15.0...
Re: Delay in 14.0-RELEASE cycle and blocking items
On 3 May 2023, at 09:53, Alexey Dokuchaev wrote: > > 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. https://bugs.freebsd.org/271047 is the exp-run bug for that; it will depend on how much ports fallout there is, and the effort required to fix things. Last time with clang 15 it took quite a while, but I hope it may be somewhat easier this time. For now it looks like the most impactful change is the new default of -std=gnu++17 for C++ mode (like gcc >= 11), since C++17 has actively removed a bunch of things which were deprecated before, for example the 'register' keyword. That tends to break older software, or software which isn't updated very often. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: Delay in 14.0-RELEASE cycle and blocking items
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. ./danfe
