[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 Jakub Jelinek changed: What|Removed |Added Target Milestone|13.3|13.4 --- Comment #22 from Jakub Jelinek --- GCC 13.3 is being released, retargeting bugs to GCC 13.4.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 Richard Biener changed: What|Removed |Added Target Milestone|13.2|13.3 --- Comment #21 from Richard Biener --- GCC 13.2 is being released, retargeting bugs to GCC 13.3.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 Jonathan Wakely 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 Richard Biener changed: What|Removed |Added Target Milestone|13.0|13.2 --- Comment #20 from Richard Biener --- GCC 13.1 is being released, retargeting bugs to GCC 13.2.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
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 ---
> Or better yet
> #include
> #include
>
> 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #18 from Jakub Jelinek ---
Or better yet
#include
#include
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #17 from Jakub Jelinek ---
(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::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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #15 from Jakub Jelinek --- (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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 Jakub Jelinek changed: What|Removed |Added CC||danglin at gcc dot gnu.org --- Comment #13 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #12 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d1389be011f0fac422e98e795c55156052c4d960
commit r13-4284-gd1389be011f0fac422e98e795c55156052c4d960
Author: Jakub Jelinek
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #11 from Jakub Jelinek --- (In reply to r...@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::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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #9 from Jakub Jelinek --- > 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::max() +#endif
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #9 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Jakub Jelinek --- > 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 . I'll file a bug about this.
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
--- Comment #7 from Jakub Jelinek ---
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::max()
+#endif
?
[Bug libstdc++/107815] 20_util/to_chars/float128_c++23.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #6 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #5) > Jonathan, shall we just #ifdef out the > std::numeric_limits::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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815
Jakub Jelinek changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org,
||redi at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
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
// 12301048576.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
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::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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from Jakub Jelinek --- >> 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 = 0x7ffe (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 (value=infinity, format_string=0xfefcec38 "%.0Lf", length=4934, buffer=0xffbfe8c8 "\177\376", '\377' ) 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #3 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #2) > > --- Comment #1 from Jakub Jelinek --- > > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jakub Jelinek --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 --- Comment #1 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107815 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
