On Mon, 30 Dec 2024, 14:28 Hans Åberg, <haberg_1@xxxxxxxxxx> wrote: > > > 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. > That's glib, a completely separate library. Glibc is the C library in GNU/Linux systems, you can't install it on macOS because that has its own C library. 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. > If users want to provide their own implementation they should do so in a different namespace.
