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

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

[ro at gcc dot gnu.org]

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

            Bug ID: 107815
           Summary: 20_util/to_chars/float128_c++23.cc FAILs
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ro at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---
            Target: sparc*-sun-solaris2.11, hppa64-hp-hpux11.11

The 20_util/to_chars/float128_c++23.cc test FAILs on SPARC (32 and 64-bit)
since it was introduced:

+FAIL: 20_util/to_chars/float128_c++23.cc execution test

There are also reports on HP-UX.

The log shows:

/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc:66:
void test(std::chars_format): Assertion 'ec2 == std::errc() && ptr2 - str2 ==
ptr1 - str1' failed.

Weirdly, if I recompile the test manually, I get this instead:

/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc:74:
void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 == ptr1'
failed.

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

[ro at gcc dot gnu.org]

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

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

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

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Can you please uncomment the
//    std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n';
and
//    std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n';
lines in the test, so that it is clear at least which test it is on?
If line 66 fails, it is a fixed printing test trying to verify
that the string created by line 60 was actually the minimal.
On SPARC Solaris, I assume long double is IEEE quad, and it is the shortest
version, so should use ryu library for both cases.
Line 74 failure is about whether the created string can be read back,
in that case for IEEE quad fast_float library can't be used and so it should
use newlocale/uselocale/strtold/uselocale/freelocale, or if the OS doesn't
support newlocale/uselocale/freelocale most likely just strtod with lost
precision (so in that case the test would fail) on line 74.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Can you please uncomment the
> //    std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n';
> and
> //    std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n';
> lines in the test, so that it is clear at least which test it is on?

Sure.  This is supposed to print u, I assume ;-)

The line before the assertion failure is

1.18973e+4932 1e+4932
/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc:66:
void test(std::chars_format): Assertion 'ec2 == std::errc() && ptr2 - str2 ==
ptr1 - str1' failed.

i.e. LDBL_MAX.

> If line 66 fails, it is a fixed printing test trying to verify
> that the string created by line 60 was actually the minimal.

It doesn't now reliably: I compiled with -g3 -O0 to be able to check
things with gdb if needed.

> On SPARC Solaris, I assume long double is IEEE quad, and it is the shortest
> version, so should use ryu library for both cases.

It is, although only ever implemented in software.

> Line 74 failure is about whether the created string can be read back,
> in that case for IEEE quad fast_float library can't be used and so it should
> use newlocale/uselocale/strtold/uselocale/freelocale, or if the OS doesn't
> support newlocale/uselocale/freelocale most likely just strtod with lost
> precision (so in that case the test would fail) on line 74.

I'm not seeing the failure on l.74 any longer, even with the default
optimization options.  There has been an effort to introduce an xpg7
locale, but that had quite a number of unresolved issues (both on AIX
and Solaris) and was never finished.  Currently, we're stuck with
generic.

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

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2)
> > --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> > Can you please uncomment the
> > //    std::cout << i << ' ' << std::string_view (str1, ptr1) << '\n';
> > and
> > //    std::cout << i << ' ' << std::string_view (str1, ptr5) << '\n';
> > lines in the test, so that it is clear at least which test it is on?
> 
> Sure.  This is supposed to print u, I assume ;-)

Oops, sure.
> 
> The line before the assertion failure is
> 
> 1.18973e+4932 1e+4932
> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/
> float128_c++23.cc:66: void test(std::chars_format): Assertion 'ec2 ==
> std::errc() && ptr2 - str2 == ptr1 - str1' failed.
> 
> i.e. LDBL_MAX.

This is weird.  If line 66 is reached, fmt must be std::chars_format::fixed
and in that case ptr1 - str1 should be 4933 and str1 should be that many chars
long string starting with
11897314953572317650857593266280070161964690526416940455296988842121635797553123923249740128484620735259020335647491268597552654335738044626726987519452614908534619587250212628458657994054044935746815
If you get just 1e+4932 when asked for fixed format, something is just wrong,
that is scientific or general format.
> 
> > If line 66 fails, it is a fixed printing test trying to verify
> > that the string created by line 60 was actually the minimal.
> 
> It doesn't now reliably: I compiled with -g3 -O0 to be able to check
> things with gdb if needed.
> 
> > On SPARC Solaris, I assume long double is IEEE quad, and it is the shortest
> > version, so should use ryu library for both cases.
> 
> It is, although only ever implemented in software.
> 
> > Line 74 failure is about whether the created string can be read back,
> > in that case for IEEE quad fast_float library can't be used and so it should
> > use newlocale/uselocale/strtold/uselocale/freelocale, or if the OS doesn't
> > support newlocale/uselocale/freelocale most likely just strtod with lost
> > precision (so in that case the test would fail) on line 74.
> 
> I'm not seeing the failure on l.74 any longer, even with the default
> optimization options.  There has been an effort to introduce an xpg7
> locale, but that had quite a number of unresolved issues (both on AIX
> and Solaris) and was never finished.  Currently, we're stuck with
> generic.

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
>> The line before the assertion failure is
>> 
>> 1.18973e+4932 1e+4932
>> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/
>> float128_c++23.cc:66: void test(std::chars_format): Assertion 'ec2 ==
>> std::errc() && ptr2 - str2 == ptr1 - str1' failed.
>> 
>> i.e. LDBL_MAX.

One thing that is also weird is that gdb prints u as infinity here, but
that may well a gdb quirk.

(gdb) p/x u
$2 = 0x7ffeffffffffffffffffffffffffffff
(gdb) ptype u
type = _Float128

> This is weird.  If line 66 is reached, fmt must be std::chars_format::fixed
> and in that case ptr1 - str1 should be 4933 and str1 should be that many chars
> long string starting with
> 11897314953572317650857593266280070161964690526416940455296988842121635797553123923249740128484620735259020335647491268597552654335738044626726987519452614908534619587250212628458657994054044935746815
> If you get just 1e+4932 when asked for fixed format, something is just wrong,
> that is scientific or general format.

I found that sprintf_ld returns 7 for the value above.  It is called
with

Thread 2 hit Breakpoint 1, 0xff0efd9c in std::(anonymous
namespace)::sprintf_ld<long double> (value=infinity, format_string=0xfefcec38
"%.0Lf", length=4934, buffer=0xffbfe8c8 "\177\376", '\377' <repeats 14 times>)
at
/vol/gcc/src/hg/master/local/libstdc++-v3/src/c++17/floating_to_chars.cc:1052

and a simple

        sprintf (buf, "%.0Lf", (long double) LDBL_MAX);

indeed returns 7.

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

[jakub at gcc dot 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?

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

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #5)
> 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?

Yes, I don't see any point trying to fix the output here. Let's just skip those
tests that are known to fail (with a comment mentioning this PR).

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

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ah, we even have PR98384 for that.
So either we add
// { dg-xfail-run-if "Non-conforming printf (see PR98384)" { *-*-solaris*
*-*-darwin* } }
to the test and thus xfail it all, or just ifdef out the max case if everything
else is fine.
Would that be
+// Solaris and Darwin have non-conforming printf, see PR98384 and PR107815.
+#if !(defined(__sun__) && defined(__svr4__)) && !defined(__MACH__)
     std::numeric_limits<std::float128_t>::max()
+#endif
?

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> 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.

It certainly seems so: the libc conversion functions use a buffer of
length DECIMAL_STRING_LENGTH, which is defined as

/*
 * Definitions for base conversion.
 */
#define DECIMAL_STRING_LENGTH 512       /* Size of buffer in decimal_record. */

in <floatingpoint.h>.

I'll file a bug about this.

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

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53953
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53953&action=edit
gcc13-pr107815.patch

Untested workaround.  I've left out Darwin there for now, because I think
it just doesn't support _Float128 right now - powerpc*-darwin* has long double
in IBM double double format, x86_64-darwin* has long double probably Intel
extended format and aarch64*-darwin*, which probably doesn't have support in
GCC yet at all, I think has long double in IEEE double format.  And _Float128
in libstdc++ is supported only if long double is IEEE quad or of libc provides
*f128 APIs (currently only glibc 2.26 does).

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

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Created attachment 53953
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53953&action=edit
> gcc13-pr107815.patch
>
> Untested workaround.  I've left out Darwin there for now, because I think

It's only necessary on sparc: i386-pc-solaris2.11 PASSed even before.
That's what I've been using successfully last night:

+// Solaris has non-conforming printf, see PR98384 and PR107815.
+#if !(defined(__sun__) && defined(__svr4__) && defined(__sparc__))
     std::numeric_limits<std::float128_t>::max()
+#endif

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

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #10)
> It's only necessary on sparc: i386-pc-solaris2.11 PASSed even before.
> That's what I've been using successfully last night:
> 
> +// Solaris has non-conforming printf, see PR98384 and PR107815.
> +#if !(defined(__sun__) && defined(__svr4__) && defined(__sparc__))
>      std::numeric_limits<std::float128_t>::max()
> +#endif

I think i386-pc-solaris2.11 doesn't do anything for the test.
While __STDCPP_FLOAT128_T__ is defined there,
_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128 shouldn't be (long double I bet is
Intel extended 80-bit format) and
_GLIBCXX_HAVE_FLOAT128_MATH is defined for now only on glibc 2.26 or later
(where the library provides sinf128 etc. APIs for _Float128).

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:d1389be011f0fac422e98e795c55156052c4d960

commit r13-4284-gd1389be011f0fac422e98e795c55156052c4d960
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Thu Nov 24 10:37:50 2022 +0100

    libstdc++: Workaround buggy printf on Solaris in to_chars/float128_c++23.cc
test [PR107815]

    As mentioned in the PR, Solaris apparently can handle right
    printf ("%.0Lf\n", 1e+202L * __DBL_MAX__);
    which prints 511 chars long number, but can't handle
    printf ("%.0Lf\n", 1e+203L * __DBL_MAX__);
    nor
    printf ("%.0Lf\n", __LDBL_MAX__);
    properly, instead of printing 512 chars long number for the former and
    4933 chars long number for the second, it handles them as
    if user asked for "%.0Le\n" in those cases.

    The following patch disables the single problematic value that fails
    in the test, and also fixes commented out debugging printouts.

    2022-11-24  Jakub Jelinek  <jakub@redhat.com>

            PR libstdc++/107815
            * testsuite/20_util/to_chars/float128_c++23.cc (test): Disable
            __FLT128_MAX__ test on Solaris.  Fix up commented out debugging
            printouts.

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

[jakub at gcc dot 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|                            |danglin at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
If it fails on HPUX, I think we need more information.  Whether it is just
max() case that fails there too or some other, and whether it fails for the
same reason or some other one (e.g. one can run the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815#c5
test and see what it prints).

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

[dave.anglin at bell dot net]

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

--- Comment #14 from dave.anglin at bell dot net ---
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/float128_c++23.cc
:77: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 ==
ptr1
' failed.
FAIL: 20_util/to_chars/float128_c++23.cc execution test

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

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to dave.anglin from comment #14)
> /home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/to_chars/
> float128_c++23.cc
> :77: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4 ==
> ptr1
> ' failed.
> FAIL: 20_util/to_chars/float128_c++23.cc execution test

Can you provide more info?
E.g. try to run the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815#c5
program and attach here what it prints, uncomment the
//    std::cout << u << ' ' << std::string_view (str1, ptr1) << '\n';
line at least to see which test it is (if also the max() or some other one)?
Thanks.

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

[dave.anglin at bell dot net]

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

--- Comment #16 from dave.anglin at bell dot net ---
This is what the test prints:
6.47518e-4966 6e-4966
xxx.cc:79: void test(std::chars_format): Assertion 'ec4 == std::errc() && ptr4
== ptr1' failed.
ABORT instruction (core dumped)

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

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to dave.anglin from comment #16)
> This is what the test prints:
> 6.47518e-4966 6e-4966
> xxx.cc:79: void test(std::chars_format): Assertion 'ec4 == std::errc() &&
> ptr4 == ptr1' failed.
> ABORT instruction (core dumped)

Ah, ok, so it is a different case, the
    std::numeric_limits<std::float128_t>::denorm_min(),
one.
6e-4966 is I believe the correct shortest scientific string representation of
the value, because nexttoward{l,f128} of that value in one direction is 0 (in
fixed or 0e+00 in scientific) and in the other direction is 12.95036e-4966
(1e-4965
in shortest scientific) and one further step 19.42554e-4966 (2e-4965 in
shortest scientific).
What fails is the from_chars for you, and from_chars when not hexadecimal
always
uses strto* functions, so I presume what HP-UX mishandles is:
#include <stdlib.h>

int
main ()
{
  char *end;
  const char *p = "6e-4966";
  long double l = strtold (p, &end);
  if (l != __LDBL_DENORM_MIN__ || end != p + 7)
    abort ();
  p = "1e-4965";
  l = strtold (p, &end);
  if (l != 2.0L * __LDBL_DENORM_MIN__ || end != p + 7)
    abort ();
  p = "2e-4965";
  l = strtold (p, &end);
  if (l != 3.0L * __LDBL_DENORM_MIN__ || end != p + 7)
    abort ();
  return 0;
}
Is that the case?
If yes, is denorm_min the only thing that doesn't work?  We can then #ifdef it
out for HP-UX with a comment.

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

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Or better yet
#include <stdlib.h>
#include <stdio.h>

int
main ()
{
  char *end;
  const char *p = "6e-4966";
  long double l = strtold (p, &end);
  if (l != __LDBL_DENORM_MIN__ || end != p + 7)
    printf ("%Le %s\n", l, end);
  p = "1e-4965";
  l = strtold (p, &end);
  if (l != 2.0L * __LDBL_DENORM_MIN__ || end != p + 7)
    printf ("%Le %s\n", l, end);
  p = "2e-4965";
  l = strtold (p, &end);
  if (l != 3.0L * __LDBL_DENORM_MIN__ || end != p + 7)
    printf ("%Le %s\n", l, end);
  return 0;
}
so that we know if it is just the denorm_min() case or also other denormals.

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

[dave.anglin at bell dot net]

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

--- Comment #19 from dave.anglin at bell dot net ---
On 2022-11-28 4:39 a.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
>
> --- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
> Or better yet
> #include <stdlib.h>
> #include <stdio.h>
>
> int
> main ()
> {
>    char *end;
>    const char *p = "6e-4966";
>    long double l = strtold (p, &end);
>    if (l != __LDBL_DENORM_MIN__ || end != p + 7)
>      printf ("%Le %s\n", l, end);
>    p = "1e-4965";
>    l = strtold (p, &end);
>    if (l != 2.0L * __LDBL_DENORM_MIN__ || end != p + 7)
>      printf ("%Le %s\n", l, end);
>    p = "2e-4965";
>    l = strtold (p, &end);
>    if (l != 3.0L * __LDBL_DENORM_MIN__ || end != p + 7)
>      printf ("%Le %s\n", l, end);
>    return 0;
> }
> so that we know if it is just the denorm_min() case or also other denormals.
I tried both test cases with a recent build of gcc-12. Neither failed at O0 or
O2. Nothing was printed.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.0                        |13.2

--- Comment #20 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.1 is being released, retargeting bugs to GCC 13.2.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-06-09
     Ever confirmed|0                           |1

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

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

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

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.3                        |13.4

--- Comment #22 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 13.3 is being released, retargeting bugs to GCC 13.4.