On Sat, 4 Jan 2025, 09:48 Hans Åberg, <haberg_1@xxxxxxxxxx> wrote: > > > On 30 Dec 2024, at 16:11, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > > > >> 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 C++ features are not implemented for some reason, as one can use the > GNU <quadmath.h> library and adding to g++ the library option -lquadmath, > as in this example: > https://stackoverflow.com/questions/5451447/quadruple-precision-in-c-gcc That has nothing to do with std::to_chars or std::format. > > > > >> 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. > > That is for user features. For unimplemented standard library features, > one would like to be able to make a hack in such a way that when the > feature becomes available, the code does not have to be rewritten except > for, at some suitable point in time, removing the hack. On large projects, > the one who wrote the hack may not be available, so it would suffice with > some straightforward cleanup. > > >
