Re: git: bc9e19dce0ab - main - Fix buildworld with gcc 12 after llvm-19 import

On 10/28/24 16:12, Dimitry Andric wrote:
> On 28 Oct 2024, at 20:56, John Baldwin <jhb@freebsd.org> wrote:
>>
>> On 10/25/24 12:08, Dimitry Andric wrote:
>>> The branch main has been updated by dim:
>>> URL: https://cgit.FreeBSD.org/src/commit/?id=bc9e19dce0abee80750e6fa04aaf979873bfe0d2
>>> commit bc9e19dce0abee80750e6fa04aaf979873bfe0d2
>>> Author:     Dimitry Andric <dim@FreeBSD.org>
>>> AuthorDate: 2024-10-25 16:07:59 +0000
>>> Commit:     Dimitry Andric <dim@FreeBSD.org>
>>> CommitDate: 2024-10-25 16:08:32 +0000
>>>      Fix buildworld with gcc 12 after llvm-19 import
>>>           Unfortunately gcc 12's is not yet capable of compiling all of libc++
>>>      19's C++23 code, which results in errors similar to:
>>>             /usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:41:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Iter, _Sent, const _Type&, _Proj)' must be a non-static member function
>>>           41 |   operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = {}) {
>>>              |   ^~~~~~~~
>>>        /usr/src/freebsd/src/contrib/llvm-project/libcxx/include/__algorithm/ranges_contains.h:48:3: error: 'static constexpr bool std::__1::ranges::__contains::__fn::operator()(_Range&&, const _Type&, _Proj)' must be a non-static member function
>>>           48 |   operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) {
>>>              |   ^~~~~~~~
>>>           Until we can get rid of gcc 12, work around this by making it compile
>>>      libc++ in C++20 mode instead.
>>>           NOTE: The resulting libc++ library will not be C++23 compatible! Please
>>>      try to avoid shipping it, and use gcc 13 instead, if you must use gcc.
>>>           PR:             280562
>>>      MFC after:      3 days
>>
>> In this case I think we probably should drop support for GCC 12 for main.  Just let me
>> know when you are thinking of merging libcxx 19 to stable branches so I can ensure they
>> build with GCC 13/14 and get our CI jobs updated before then.
> 
> It depends a bit on how many ports still need to be fixed, and of course when 13.5 and 14.2 are done. After those I will probably do the merges.
> 
> That said, is gcc 13 good for all arches we want to support? In the past we still kept a few old gcc versions alive because they were the only one that could build for $OBSOLETE_ARCH.

I am only aware that GCC 12+ can build amd64 world + GENERIC currently.  I believe
aarch64 is close.  i386 is also pretty close (but I care less about it).   riscv64
needs a libatomic since GCC doesn't inline atomics as much as clang.  I haven't
really tried powerpc much.

-- 
John Baldwin