`./configure` fails for clang-14 on Ubuntu 23.10 #29161

$ clang-14 -v
Ubuntu clang version 14.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13
Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13
Candidate multilib: .;@m64
Selected multilib: .;@m64

$ ./configure CC=clang-14 CXX=clang++-14
...
checking whether std::atomic can be used without link library... no
checking whether std::atomic needs -latomic... no
configure: error: in `/bitcoin':
configure: error: cannot figure out how to use std::atomic
See `config.log' for more details

Here is an excerpt from the config.log:

configure:25695: checking whether std::atomic can be used without link library
configure:25722: clang++-14 -std=c++20 -o conftest -g -O2 -pthread   conftest.cpp  >&5
In file included from conftest.cpp:32:
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2320:48: error: call to consteval function 'std::chrono::hh_mm_ss::_S_fractional_width' is not a constant 
expression
        static constexpr unsigned fractional_width = {_S_fractional_width()};
                                                      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2320:48: note: undefined function '_S_fractional_width' cannot be used in a constant expression
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2275:2: note: declared here
        _S_fractional_width()
        ^
1 error generated.

That is a bug in clang-14, fixed in 15. Reproducer:

template <class A>
struct ch {
    static consteval unsigned w() { return {}; };
    static constexpr unsigned bar{w()};
};

int main() {}

I don't understand why this isn't caught by CI. Maybe libc++ somehow works around the bug in the corresponding clang?

Not sure how to fix it. The easiest would obviously be to bump the minimum required to clang-15. However, I am not sure if that works for macOS users.

I don't understand why this isn't caught by CI. Maybe libc++ somehow works around the bug in the corresponding clang?

We do not have a combination of clang-14 with libstdc++-13-dev in the CI.

Maybe libc++ somehow works around the bug in the corresponding clang?

The issue is only when Clang is being used with libstdc++. i.e:

#include <chrono>

int main() { return 0;}

clang-13 test.cpp -O2 -std=c++20
...
#include <...> search starts here:
 /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13
 /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/x86_64-linux-gnu/c++/13
 /usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/backward
 /usr/lib/llvm-13/lib/clang/13.0.1/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
...
In file included from test.cpp:1:
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2320:48: error: call to consteval function 'std::chrono::hh_mm_ss::_S_fractional_width' is not a constant expression
        static constexpr unsigned fractional_width = {_S_fractional_width()};
                                                      ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2320:48: note: undefined function '_S_fractional_width' cannot be used in a constant expression
/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/chrono:2275:2: note: declared here
        _S_fractional_width()
        ^
1 error generated.

clang-13 test.cpp -O2 -std=c++20 -stdlib=libc++
...
#include <...> search starts here:
 /usr/lib/llvm-13/bin/../include/c++/v1
 /usr/lib/llvm-13/lib/clang/13.0.1/include
 /usr/local/include
 /usr/include/x86_64-linux-gnu
 /usr/include
...

I don't understand why this isn't caught by CI. Maybe libc++ somehow works around the bug in the corresponding clang?

Oh, I guess libc++ doesn't use consteval, but constexpr:

https://github.com/llvm/llvm-project/blob/9b7cf5bfb08b6e506216ef354dfd61adb15acbff/libcxx/include/__chrono/hh_mm_ss.h#L42

Going to close this as wontfix. If someone is using an operating system that is modern enough to be shipping GCC 13.2 and Clang 16 as the default compilers, then I'd suggest using either of those as their compiler. Also given that this is a bug in Clang, but only when coupled with a certain version of libstdc++, it's not easy for us to "fix". An alternative is to try with libc++. For older systems, clang-14 remains supported (for now).