> On 30 Dec 2024, at 14:24, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > > On Sun, 29 Dec 2024 at 14:57, Hans Åberg <haberg_1@xxxxxxxxxx> wrote: >> >> >>> On 29 Dec 2024, at 15:16, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: >>> >>> On Sun, 29 Dec 2024 at 10:01, Hans Åberg via Gcc-help >>> <gcc-help@xxxxxxxxxxx> wrote: >>>> >>>> When checking the GCC 14.2 implementation of C++23 fixed width floating-point types in the header <stdfloat> [1]: >>>> >>>> The page [2] says that one should be able to write std::float128_t using std::formatter as it is using std::to_chars which is required to support all arithmetic type, but it does not work with GCC. >>> >>> It works fine for me. >>> >>>> But the wording suggests it has been working with GCC. >>> >>> And still is working. >>> >>> If it's not working for you, it must be a limitation of your OS, which >>> you haven't told us. >> >> It is MacOS 15.2, Silicon, but I think the error is the same on Intel, with >> % g++ --version >> g++ (MacPorts gcc14 14.2.0_3+stdlib_flag) 14.2.0 > > That's the problem then. std::to_chars is only defined for float128 > under these conditions: > > #if defined(__STDCPP_FLOAT128_T__) && > defined(_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128) > ... > #elif defined(__STDCPP_FLOAT128_T__) && defined(_GLIBCXX_HAVE_FLOAT128_MATH) > ... > #endif > > The HAVE_FLOAT128_MATH macro is currently only defined for Glibc 2.26 > and later, on targets that support __float128. The two GLIBCXX macros are not defined here, both on arm64 and x86_64. Some of the std::float128_t functions are defined, others are not: std::fmod seems defined, whereas std::floor and std::abs are not (on arm64). Though Glibc2 is available in MacPorts, I can't see how it should enter the picture. https://ports.macports.org/port/glib2/details/ https://ports.macports.org/port/gcc14/details/ > Maybe it would make the errors clearer if we did this: > > --- a/libstdc++-v3/include/std/charconv > +++ b/libstdc++-v3/include/std/charconv > @@ -913,6 +913,11 @@ namespace __detail > to_chars_result to_chars(char* __first, char* __last, _Float128 __value, > chars_format __fmt, int __precision) noexcept; > #endif > +#else > + // No libc support for formatting 128-bit floating-point types. > + to_chars_result to_chars(char*, char*, _Float128) = delete; > + to_chars_result to_chars(char*, char*, _Float128, chars_format) = delete; > + to_chars_result to_chars(char*, char*, _Float128, chars_format, > int) = delete; > #endif Even though it might help readability of diagnostics, the use of the keyword “delete” might destroy the implementation of hacks, as the meaning is to prohibit what is semantically wrong, not what is currently missing and might be added later on. There ought to be a keyword “unimplemented” that allows user implementation on top of it.
