[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org,
                   |                            |redi at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
You're right.
This is the:
    else if (fmt == chars_format::fixed && fd.exponent >= 0)
      {
        // The Ryu exponent is positive, and so this number's shortest
        // representation is a whole number, to be formatted in fixed instead
        // of scientific notation "as if by std::printf".  This means we may
        // need to print more digits of the IEEE mantissa than what the
        // shortest scientific form given by Ryu provides.
        //
        // For instance, the exactly representable number
        // 12300000000000001048576.0 has as its shortest scientific
        // representation 123e+22, so in this case fd.mantissa is 123 and
        // fd.exponent is 22, which doesn't have enough information to format
        // the number exactly.  So we defer to Ryu's d2fixed_buffered_n with
        // precision=0 to format the number in the general case here.
case for which ryu doesn't handle d2fixed_buffered_n for wider than double and
so use
            const int output_length = sprintf_ld(buffer,
                                                 expected_output_length + 1,
                                                 "%.0Lf", value);
and Solaris apparently violates ISO C99 in producing for the last 3 printf
calls scientifix values rather than fixed:
#include <stdio.h>

int
main ()
{
  printf ("%.0f\n", __DBL_MAX__);
  printf ("%.0Lf\n", (long double) __DBL_MAX__);
  printf ("%.0Lf\n", 2.0L * __DBL_MAX__);
  printf ("%.0Lf\n", 1e+202L * __DBL_MAX__);
  printf ("%.0Lf\n", 1e+203L * __DBL_MAX__);
  printf ("%.0Lf\n", (long double) __DBL_MAX__ * (long double) __DBL_MAX__);
  printf ("%.0Lf\n", __LDBL_MAX__);
}
The 1e+202L * __DBL_MAX__ number is:
1797693134862315708145274237317043363780293901488132670510305396153274401107450252964067353821542098883610426262810674725334159395885309388675990127492090757713383689567223448511120723139743573688679064280172265585993927318314820133831157520860190820700571151387146478495139447053313076754655788391539857757373041885363113533243178943928496535556954517148959372706003524689906194839868952331046086040494963209033312113173876118835007579814542996644987978064090838995977878567921521624960885877081515358704107520
which is 511 bytes long excluding '\0' terminator, so bet they have somewhere
fixed length temporary buffer or what.

Jonathan, shall we just #ifdef out the
std::numeric_limits<std::float128_t>::max()
test in that test for Solaris and maybe HP-UX if it suffers from the same bug?