* [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
@ 2020-12-21 20:28 ` ppalka at gcc dot gnu.org
2020-12-22 9:23 ` ro at gcc dot gnu.org
` (39 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2020-12-21 20:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-12-21
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
2020-12-21 20:28 ` [Bug libstdc++/98384] " ppalka at gcc dot gnu.org
@ 2020-12-22 9:23 ` ro at gcc dot gnu.org
2021-01-05 9:10 ` [Bug libstdc++/98384] [11 Regression] " rguenth at gcc dot gnu.org
` (38 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ro at gcc dot gnu.org @ 2020-12-22 9:23 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Rainer Orth <ro at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ro at gcc dot gnu.org
Build|powerpc64-linux-gnu |
Host|powerpc64-linux-gnu |
Target|powerpc64-linux-gnu |powerpc64-linux-gnu,
| |*-*-solaris2.11
--- Comment #1 from Rainer Orth <ro at gcc dot gnu.org> ---
The test FAILs in the same way on Solaris 11, both sparc and x86, 32 and
64-bit.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
2020-12-21 20:28 ` [Bug libstdc++/98384] " ppalka at gcc dot gnu.org
2020-12-22 9:23 ` ro at gcc dot gnu.org
@ 2021-01-05 9:10 ` rguenth at gcc dot gnu.org
2021-01-07 13:04 ` iains at gcc dot gnu.org
` (37 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-05 9:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|new test case |[11 Regression] new test
|20_util/to_chars/long_doubl |case
|e.cc in r11-6249 fails on |20_util/to_chars/long_doubl
|powerpc64 BE |e.cc in r11-6249 fails on
| |powerpc64 BE
Target Milestone|--- |11.0
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2021-01-05 9:10 ` [Bug libstdc++/98384] [11 Regression] " rguenth at gcc dot gnu.org
@ 2021-01-07 13:04 ` iains at gcc dot gnu.org
2021-01-07 15:42 ` ppalka at gcc dot gnu.org
` (36 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: iains at gcc dot gnu.org @ 2021-01-07 13:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2020-12-21 00:00:00 |2021-1-7
Target|powerpc64-linux-gnu, |powerpc64-linux-gnu,
|*-*-solaris2.11 |*-*-solaris2.11 *-darwin*
CC| |iains at gcc dot gnu.org
--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> ---
likewise for all Darwin versions from Darwin8 through 20 and all archs
(powerpc, i686, x86_64 and the experimental aarch64 port).
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2021-01-07 13:04 ` iains at gcc dot gnu.org
@ 2021-01-07 15:42 ` ppalka at gcc dot gnu.org
2021-01-07 16:41 ` iains at gcc dot gnu.org
` (35 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-01-07 15:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Candidate patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563000.html
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2021-01-07 15:42 ` ppalka at gcc dot gnu.org
@ 2021-01-07 16:41 ` iains at gcc dot gnu.org
2021-01-07 17:42 ` cvs-commit at gcc dot gnu.org
` (34 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: iains at gcc dot gnu.org @ 2021-01-07 16:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #3)
> Candidate patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563000.html
thanks!
On Darwin, the test case now builds (checked on a 32b host [powerpc] with a 64b
multilib) and a 64b (x86_64) host. The 32b multilib xfails the execute (as
expected w/out int128 support)
On both powerpc (64b multilib) and x86_64:
test01 fails with :
src-local/gcc-master/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:136:
void test01(): Assertion '!strcmp(to_chars_buffer, printf_buffer+strlen("0x"))'
failed.
(not analysed why yet).
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2021-01-07 16:41 ` iains at gcc dot gnu.org
@ 2021-01-07 17:42 ` cvs-commit at gcc dot gnu.org
2021-01-07 17:55 ` ppalka at gcc dot gnu.org
` (33 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-01-07 17:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:19f3c433cdc92f1ad6c37f182d5034b03c54afef
commit r11-6524-g19f3c433cdc92f1ad6c37f182d5034b03c54afef
Author: Patrick Palka <ppalka@redhat.com>
Date: Thu Jan 7 12:41:14 2021 -0500
libstdc++: Fix long double to_chars testcase [PR98384]
The testcase was failing to compile on some targets due to its use of
the non-standard functions nextupl and nextdownl. This patch makes the
testcase instead use the C99 function nexttowardl in an equivalent way.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Use nexttowardl
instead of the non-standard nextupl and nextdownl.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2021-01-07 17:42 ` cvs-commit at gcc dot gnu.org
@ 2021-01-07 17:55 ` ppalka at gcc dot gnu.org
2021-01-08 9:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (32 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-01-07 17:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #4)
> (In reply to Patrick Palka from comment #3)
> > Candidate patch:
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563000.html
>
> thanks!
>
> On Darwin, the test case now builds (checked on a 32b host [powerpc] with a
> 64b multilib) and a 64b (x86_64) host. The 32b multilib xfails the execute
> (as expected w/out int128 support)
>
> On both powerpc (64b multilib) and x86_64:
>
> test01 fails with :
> src-local/gcc-master/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:
> 136: void test01(): Assertion '!strcmp(to_chars_buffer,
> printf_buffer+strlen("0x"))' failed.
>
> (not analysed why yet).
Thanks for testing! Hmm, that execute failure is surprising. I wonder just
how much we're diverging from the output of printf here. If possible, could
you let me know the value of the locals 'to_chars_buffer', 'printf_buffer',
'precision' and 'testcase' (ideally in hex form) at the point of the assertion
failure?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (7 preceding siblings ...)
2021-01-07 17:55 ` ppalka at gcc dot gnu.org
@ 2021-01-08 9:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
2021-01-12 16:35 ` ppalka at gcc dot gnu.org
` (31 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2021-01-08 9:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
[...]
> Thanks for testing! Hmm, that execute failure is surprising. I wonder just
> how much we're diverging from the output of printf here. If possible, could
> you let me know the value of the locals 'to_chars_buffer', 'printf_buffer',
> 'precision' and 'testcase' (ideally in hex form) at the point of the assertion
> failure?
I'm seeing exactly the same failure mode on Solaris, both sparc and x86:
32-bit compilation PASSes, execution XFAILed, 64-bit compilation PASSes,
too, but execution FAILs with the same assertion failure.
Here's what gdb prints for those variables (with the test compiled with
-g3 -O0 where the assertion still fails):
(gdb) p to_chars_buffer
$1 = "f.", 'f' <repeats 14 times>, "ep+5380", '\000' <repeats 1000 times>
(gdb) p printf_buffer
$2 = "0x1.", 'f' <repeats 15 times>, "cp+5383", '\000' <repeats 997 times>
(gdb) p precision
No symbol "precision" in current context.
(gdb) p testcase
$3 = 5.56540347525605847154e+1620
(gdb) p/x testcase
$5 = 0x7fffffffffffffff
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (8 preceding siblings ...)
2021-01-08 9:30 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2021-01-12 16:35 ` ppalka at gcc dot gnu.org
2021-01-14 11:13 ` rguenth at gcc dot gnu.org
` (30 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-01-12 16:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #8 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #7)
> > --- Comment #6 from Patrick Palka <ppalka at gcc dot gnu.org> ---
> [...]
> > Thanks for testing! Hmm, that execute failure is surprising. I wonder just
> > how much we're diverging from the output of printf here. If possible, could
> > you let me know the value of the locals 'to_chars_buffer', 'printf_buffer',
> > 'precision' and 'testcase' (ideally in hex form) at the point of the assertion
> > failure?
>
> I'm seeing exactly the same failure mode on Solaris, both sparc and x86:
> 32-bit compilation PASSes, execution XFAILed, 64-bit compilation PASSes,
> too, but execution FAILs with the same assertion failure.
>
> Here's what gdb prints for those variables (with the test compiled with
> -g3 -O0 where the assertion still fails):
>
> (gdb) p to_chars_buffer
> $1 = "f.", 'f' <repeats 14 times>, "ep+5380", '\000' <repeats 1000 times>
> (gdb) p printf_buffer
> $2 = "0x1.", 'f' <repeats 15 times>, "cp+5383", '\000' <repeats 997 times>
> (gdb) p precision
> No symbol "precision" in current context.
> (gdb) p testcase
> $3 = 5.56540347525605847154e+1620
> (gdb) p/x testcase
> $5 = 0x7fffffffffffffff
Thanks for this helpful info.
>From what I can tell, the difference in output here is basically harmless. The
two hexadecimal forms (in to_chars_buffer and printf_buffer) are equivalent,
though ours is one digit shorter. Both hexadecimal forms are also valid
results of printf's %La specifier for this value.
Since the standard underspecifies the result of printf's %a specifier, and
since there's apparent implementation divergence, we shouldn't be verifying the
hex output of std::to_chars by comparing it with that of printf. Instead we
should compare with the known correct value, or perhaps verify that applying
std::from_chars on the output yields the original value.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (9 preceding siblings ...)
2021-01-12 16:35 ` ppalka at gcc dot gnu.org
@ 2021-01-14 11:13 ` rguenth at gcc dot gnu.org
2021-02-12 15:02 ` jakub at gcc dot gnu.org
` (29 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-01-14 11:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (10 preceding siblings ...)
2021-01-14 11:13 ` rguenth at gcc dot gnu.org
@ 2021-02-12 15:02 ` jakub at gcc dot gnu.org
2021-02-23 2:49 ` cvs-commit at gcc dot gnu.org
` (28 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-02-12 15:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think glibc %a printing uses 0x1.xxxx (for normalized values) at least for
float/double and the IEEE quad long doubles, but uses 0xf.xxxx printing etc.
for the 80-bit long doubles. My personal preference would be to always use
0x1.xxxx for normalized numbers and for denormals 0x0.xxxx, I think it is less
surprising to users, and transforming one form to another is pretty easy.
And agree on the tests just trying to parse the returned string back to see if
it is the original value.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (11 preceding siblings ...)
2021-02-12 15:02 ` jakub at gcc dot gnu.org
@ 2021-02-23 2:49 ` cvs-commit at gcc dot gnu.org
2021-02-23 16:55 ` ppalka at gcc dot gnu.org
` (27 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-23 2:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:198c56052ea8cce4196e60c0dc3187bf3d67a786
commit r11-7337-g198c56052ea8cce4196e60c0dc3187bf3d67a786
Author: Patrick Palka <ppalka@redhat.com>
Date: Mon Feb 22 21:49:25 2021 -0500
libstdc++: Fix endianness issue with IBM long double [PR98384]
The code in std::to_chars for extracting the high- and low-order parts
of an IBM long double value does the right thing on powerpc64le, but not
on powerpc64be. This patch makes the extraction endian-agnostic, which
fixes the execution FAIL of to_chars/long_double.cc on powerpc64be.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* src/c++17/floating_to_chars.cc (get_ieee_repr): Extract
the high- and low-order parts from an IBM long double value
in an endian-agnostic way.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (12 preceding siblings ...)
2021-02-23 2:49 ` cvs-commit at gcc dot gnu.org
@ 2021-02-23 16:55 ` ppalka at gcc dot gnu.org
2021-02-24 9:58 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (26 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-02-23 16:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #11 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #9)
> I think glibc %a printing uses 0x1.xxxx (for normalized values) at least for
> float/double and the IEEE quad long doubles, but uses 0xf.xxxx printing etc.
> for the 80-bit long doubles. My personal preference would be to always use
> 0x1.xxxx for normalized numbers and for denormals 0x0.xxxx, I think it is
> less surprising to users, and transforming one form to another is pretty
> easy.
Yeah, currently to_chars hex output mimics glibc's choice of leading hex digit.
But always using 0/1, even for 80-bit long double sounds good to me too.
FWIW, I think the shortest hex form for some number is at most 3 characters
shorter than any other conforming hex form, e.g. 1.2p+12 vs 9p+9.
> And agree on the tests just trying to parse the returned string back to see
> if it is the original value.
I posted a patch at
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html that does
this, but also salvages the verification via printf by first checking if the
leading hex digit of the printf output agrees with that of to_chars.
Conveniently, the patch sidesteps the question of choosing a consistent
representation vs shortest representation :)
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (13 preceding siblings ...)
2021-02-23 16:55 ` ppalka at gcc dot gnu.org
@ 2021-02-24 9:58 ` ro at CeBiTec dot Uni-Bielefeld.DE
2021-02-24 15:14 ` ppalka at gcc dot gnu.org
` (25 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2021-02-24 9:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #11 from Patrick Palka <ppalka at gcc dot gnu.org> ---
> I posted a patch at
> https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html that does
> this, but also salvages the verification via printf by first checking if the
> leading hex digit of the printf output agrees with that of to_chars.
> Conveniently, the patch sidesteps the question of choosing a consistent
> representation vs shortest representation :)
I've just tested the patch on both i386-pc-solaris2.11 and
sparc-sun-solaris2.11 (32 and 64-bit each): as before, the 32-bit test
XFAILs while the 64-bit test continues to FAIL:
before:
/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:104:
void test01(): Assertion '!strcmp(to_chars_buffer, printf_buffer+strlen("0x"))'
failed.
now:
/vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:192:
void test02(): Assertion '!memcmp(printf_buffer, to_chars_buffer,
output_length)' failed.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (14 preceding siblings ...)
2021-02-24 9:58 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2021-02-24 15:14 ` ppalka at gcc dot gnu.org
2021-02-24 15:42 ` ro at CeBiTec dot Uni-Bielefeld.DE
` (24 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-02-24 15:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #13 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #12)
> > --- Comment #11 from Patrick Palka <ppalka at gcc dot gnu.org> ---
> > I posted a patch at
> > https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html that does
> > this, but also salvages the verification via printf by first checking if the
> > leading hex digit of the printf output agrees with that of to_chars.
> > Conveniently, the patch sidesteps the question of choosing a consistent
> > representation vs shortest representation :)
>
> I've just tested the patch on both i386-pc-solaris2.11 and
> sparc-sun-solaris2.11 (32 and 64-bit each): as before, the 32-bit test
> XFAILs while the 64-bit test continues to FAIL:
>
> before:
>
> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/
> long_double.cc:104: void test01(): Assertion '!strcmp(to_chars_buffer,
> printf_buffer+strlen("0x"))' failed.
>
> now:
>
> /vol/gcc/src/hg/master/local/libstdc++-v3/testsuite/20_util/to_chars/
> long_double.cc:192: void test02(): Assertion '!memcmp(printf_buffer,
> to_chars_buffer, output_length)' failed.
Thanks for testing. I was able to reproduce the 64-bit execution FAIL on
sparc-sun-solaris2.11 (using the gcc211 compile farm machine).
Digging deeper, it seems the test is failing ultimately due to pecularities
with the system printf implementation. For example, when I compile+run the
following
#include <cstdio>
int main() {
printf("%La\n", 1.0L);
printf("%L.1000f\n", 1.0L);
printf("%Lf\n", 0x1.13492ffd6ec7341068e0176a737dp+3384L);
}
the output I get is
0x1.0000000000000000000000000000p+0
1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000e+00
5.212539e+1018
So:
1. The hex-form conversion specifier doesn't trim trailing zeroes.
2. The fixed-form conversion specifier sometimes outputs the
scientific-notation suffix "e+00".
3. The fixed-form conversion specifier sometimes outputs the scientific form.
Each of the to_chars/printf mismatches I've looked at seem to be caused by one
of these three issues. Should we just XFAIL the test on Solaris?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (15 preceding siblings ...)
2021-02-24 15:14 ` ppalka at gcc dot gnu.org
@ 2021-02-24 15:42 ` ro at CeBiTec dot Uni-Bielefeld.DE
2021-02-24 15:48 ` jakub at gcc dot gnu.org
` (23 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ro at CeBiTec dot Uni-Bielefeld.DE @ 2021-02-24 15:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #13 from Patrick Palka <ppalka at gcc dot gnu.org> ---
[...]
> So:
>
> 1. The hex-form conversion specifier doesn't trim trailing zeroes.
Which according to ISO C 2017, p.228, is allowed: "trailing zeros may
be omitted".
> 2. The fixed-form conversion specifier sometimes outputs the
> scientific-notation suffix "e+00".
This is unexpected indeed.
> 3. The fixed-form conversion specifier sometimes outputs the scientific form.
Same. However, g++ -Wall complains:
pr98384.cc: In function ‘int main()’:
pr98384.cc:5:13: warning: unknown conversion type character ‘.’ in format
[-Wformat=]
5 | printf("%L.1000f\n", 1.0L);
| ^
pr98384.cc:5:10: warning: too many arguments for format [-Wformat-extra-args]
5 | printf("%L.1000f\n", 1.0L);
| ^~~~~~~~~~~~
Compiling the equivalent C version with Studio 12.6 cc gives:
"pr98384.c", line 6: warning: conversion of hex floating-point constant cannot
be represented exactly in its evaluation format
> Each of the to_chars/printf mismatches I've looked at seem to be caused by one
> of these three issues. Should we just XFAIL the test on Solaris?
Only if it's clear that those outputs are in violation of the standard
and the inputs are valid: the warnings above cast some doubt upon the
latter.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (16 preceding siblings ...)
2021-02-24 15:42 ` ro at CeBiTec dot Uni-Bielefeld.DE
@ 2021-02-24 15:48 ` jakub at gcc dot gnu.org
2021-02-24 16:16 ` ppalka at gcc dot gnu.org
` (22 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-02-24 15:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
printf("%L.1000f\n", 1.0L);
The length modifier needs to come after precision, not before it, so
you should be using
printf("%.1000Lf\n", 1.0L);
instead.
But the test nor libstdc++ itself doesn't do that, does it?
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (17 preceding siblings ...)
2021-02-24 15:48 ` jakub at gcc dot gnu.org
@ 2021-02-24 16:16 ` ppalka at gcc dot gnu.org
2021-02-24 16:26 ` iains at gcc dot gnu.org
` (21 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-02-24 16:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #16 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #14)
> > --- Comment #13 from Patrick Palka <ppalka at gcc dot gnu.org> ---
> [...]
> > So:
> >
> > 1. The hex-form conversion specifier doesn't trim trailing zeroes.
>
> Which according to ISO C 2017, p.228, is allowed: "trailing zeros may
> be omitted".
Ack.
>
> > 2. The fixed-form conversion specifier sometimes outputs the
> > scientific-notation suffix "e+00".
>
> This is unexpected indeed.
>
> > 3. The fixed-form conversion specifier sometimes outputs the scientific form.
>
> Same. However, g++ -Wall complains:
>
> pr98384.cc: In function ‘int main()’:
> pr98384.cc:5:13: warning: unknown conversion type character ‘.’ in format
> [-Wformat=]
> 5 | printf("%L.1000f\n", 1.0L);
> | ^
> pr98384.cc:5:10: warning: too many arguments for format [-Wformat-extra-args]
> 5 | printf("%L.1000f\n", 1.0L);
> | ^~~~~~~~~~~~
Whoops, that line should say printf("%.1000Lf\n", 1.0L) as Jakub pointed out.
With that change the testcase in #c13 should be valid, and the unexpected
"e+00" suffix is still present in the output.
>
> Compiling the equivalent C version with Studio 12.6 cc gives:
>
> "pr98384.c", line 6: warning: conversion of hex floating-point constant
> cannot be represented exactly in its evaluation format
>
> > Each of the to_chars/printf mismatches I've looked at seem to be caused by one
> > of these three issues. Should we just XFAIL the test on Solaris?
>
> Only if it's clear that those outputs are in violation of the standard
> and the inputs are valid: the warnings above cast some doubt upon the
> latter.
It seems the second and third issue alone make the printf implementation
nonconforming (but not the first issue as you pointed out). Ideally the
libstdc++ testcase ought to not assume the 'a' printf specifier trims trailing
zeros, but even with that fixed it seems we still might have to XFAIL on
Solaris due to the second and third issue?
(In reply to Jakub Jelinek from comment #15)
> printf("%L.1000f\n", 1.0L);
>
> The length modifier needs to come after precision, not before it, so
> you should be using
> printf("%.1000Lf\n", 1.0L);
> instead.
> But the test nor libstdc++ itself doesn't do that, does it?
Fortunately not, I just messed up transforming 'print("%.*Lf", 1000, ...)' into
'printf("%.1000Lf", ...)' inline in the #c13 testcase :)
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (18 preceding siblings ...)
2021-02-24 16:16 ` ppalka at gcc dot gnu.org
@ 2021-02-24 16:26 ` iains at gcc dot gnu.org
2021-02-24 16:45 ` ppalka at gcc dot gnu.org
` (20 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: iains at gcc dot gnu.org @ 2021-02-24 16:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #17 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #16)
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #14)
> > > --- Comment #13 from Patrick Palka <ppalka at gcc dot gnu.org> ---
[..]
> > Which according to ISO C 2017, p.228, is allowed: "trailing zeros may
> > be omitted".
>
> Ack.
Darwin also produces the trailing zeros.
For the #c13 test with Jakub's correction (x86_64-darwin16):
0x8p-3
1.0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
52125389249491778072998734723901065658344854339911180645920036689145962141728255198944006625782458697361398052188320725945500187466736263651898402197281418601194866666114137406392103946594069442529773439118695632979327870214580049152501161485502649632222947505166386519043250141814251625491416037224583585022738137785584320282641248955105327838594556002939771000202665231335009645885816784092727359474711102827146567529583202954627003333796860257717072319132149129951852089814871685652019158129352457876413077731822944690893023783688156197557228348257706445069058168217860984489364449216192153697464386313372616125802493006313011849107453714600675828600445923171763793130115636080004121099460216359522049035859262314715833943305021976057857853126510419437495501816388939228067001371011547274042754738463678560481977277814562542528910043287233881513857018892008936293030725951345023187328378120620598203530289119602404678381135515657024501288339144721058539176378789830725427845326462393386911535328986994985182586470400.000000
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (19 preceding siblings ...)
2021-02-24 16:26 ` iains at gcc dot gnu.org
@ 2021-02-24 16:45 ` ppalka at gcc dot gnu.org
2021-02-24 17:26 ` cvs-commit at gcc dot gnu.org
` (19 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-02-24 16:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #18 from Patrick Palka <ppalka at gcc dot gnu.org> ---
FWIW, here's a complete corrected version of the Solaris test in comment #13
which should be fully free of warnings:
#include <cstdio>
int main() {
printf("%La\n", 1.0L); // trailing zeros present (not nonconforming, but
unexpected by the libstdc++ testcase)
printf("%.1000Lf\n", 1.0L); // output contains e+00 (nonconforming?)
printf("%Lf\n", 1e1000L); // output is in scientific notation
(nonconforming?)
}
(In reply to Iain Sandoe from comment #17)
> (In reply to Patrick Palka from comment #16)
> > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #14)
> > > > --- Comment #13 from Patrick Palka <ppalka at gcc dot gnu.org> ---
>
> [..]
> > > Which according to ISO C 2017, p.228, is allowed: "trailing zeros may
> > > be omitted".
> >
> > Ack.
>
> Darwin also produces the trailing zeros.
>
> For the #c13 test with Jakub's correction (x86_64-darwin16):
>
> 0x8p-3
Thanks. Trailing zeros in the second line of output are expected (and
required). It's the hex form (on the first line of output) that the libstdc++
testcase doesn't expect to contain trailing zeros, so I don't anticipate any
issues with printf on Darwin. So my hope is that the
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html resolves
the long_double.cc FAIL on 64-bit Darwin as well.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (20 preceding siblings ...)
2021-02-24 16:45 ` ppalka at gcc dot gnu.org
@ 2021-02-24 17:26 ` cvs-commit at gcc dot gnu.org
2021-02-27 16:17 ` iains at gcc dot gnu.org
` (18 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-02-24 17:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:70aa0e6eef9d65744f37adc2a3cffef1a8217dc1
commit r11-7367-g70aa0e6eef9d65744f37adc2a3cffef1a8217dc1
Author: Patrick Palka <ppalka@redhat.com>
Date: Wed Feb 24 12:24:43 2021 -0500
libstdc++: Robustify long double std::to_chars testcase [PR98384]
The long double std::to_chars testcase currently verifies the
correctness of its output by comparing it to that of printf, so if
there's a mismatch between to_chars and printf, the test FAILs. This
works well for the scientific, fixed and general formatting modes,
because the corresponding printf conversion specifiers (%e, %f and %g)
are rigidly specified.
But this doesn't work well for the hex formatting mode because the
corresponding printf conversion specifier %a is more flexibly specified.
For instance, the hexadecimal forms 0x1p+0, 0x2p-1, 0x4p-2 and 0x8p-3
are all equivalent and valid outputs of the %a specifier for the number 1.
The apparent freedom here is the choice of leading hex digit -- the
standard just requires that the leading hex digit is nonzero for
normalized numbers.
Currently, our hexadecimal formatting implementation uses 0/1/2 as the
leading hex digit for floating point types that have an implicit leading
mantissa bit which in practice means all supported floating point types
except x86 long double. The latter type has a 64 bit mantissa with an
explicit leading mantissa bit, and for this type our implementation uses
the most significant four bits of the mantissa as leading hex digit.
This seems to be consistent with most printf implementations, but not
all, as PR98384 illustrates.
In order to avoid false-positive FAILs due to arbitrary disagreement
between to_chars and printf about the choice of leading hex digit, this
patch makes the testcase's verification via printf conditional on the
leading hex digits first agreeing. An additional verification step is
also added: round-tripping the output of to_chars through from_chars
should recover the value exactly.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Include <optional>.
(test01): Simplify verifying the nearby values by using a
2-iteration loop and a dedicated output buffer to check that the
nearby values are different. Factor out the printf-based
verification into a local function, and check that the leading
hex digits agree before comparing to the output of printf. Also
verify the output by round-tripping it through from_chars.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (21 preceding siblings ...)
2021-02-24 17:26 ` cvs-commit at gcc dot gnu.org
@ 2021-02-27 16:17 ` iains at gcc dot gnu.org
2021-02-27 16:49 ` dje at gcc dot gnu.org
` (17 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: iains at gcc dot gnu.org @ 2021-02-27 16:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> ---
still failing on Darwin at r11-7425 - is that expected (i.e. patches pending)
or more analysis needed?
long_double.cc:83: test01()::<lambda(char*, long double, std::optional<int>)>:
Assertion '!strcmp(begin, printf_buffer+strlen("0x"))' failed.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (22 preceding siblings ...)
2021-02-27 16:17 ` iains at gcc dot gnu.org
@ 2021-02-27 16:49 ` dje at gcc dot gnu.org
2021-03-03 14:28 ` ppalka at gcc dot gnu.org
` (16 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: dje at gcc dot gnu.org @ 2021-02-27 16:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #21 from David Edelsohn <dje at gcc dot gnu.org> ---
It similarly continues to fail on AIX:
long_double.cc:192: void test02(): Assertion '!memcmp(printf_buffer,
to_chars_buffer, output_length)' failed.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (23 preceding siblings ...)
2021-02-27 16:49 ` dje at gcc dot gnu.org
@ 2021-03-03 14:28 ` ppalka at gcc dot gnu.org
2021-03-05 2:37 ` dje at gcc dot gnu.org
` (15 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-03-03 14:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #22 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Thanks for the heads up. Continued execution FAILs on Darwin and AIX even
after the most recent patches is certainly unexpected :( I hope to analyze and
address this soon.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (24 preceding siblings ...)
2021-03-03 14:28 ` ppalka at gcc dot gnu.org
@ 2021-03-05 2:37 ` dje at gcc dot gnu.org
2021-03-08 17:42 ` ppalka at gcc dot gnu.org
` (14 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: dje at gcc dot gnu.org @ 2021-03-05 2:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #23 from David Edelsohn <dje at gcc dot gnu.org> ---
The AIX failure is:
printf_buffer=
1.4426950408889633870046509400708600880000000000000000000000000000000000000000000000000000000000000000
to_chars_buffer=
1.4426950408889633870046509400708600878715515136718750000000000000000000000000000000000000000000000000??/?P00001.4426950408889633870046509400708600880000000000000000000000000000000000000000000000000000000000000000
output_length=
102
./long_double.cc:194: void test02(): Assertion '!memcmp(printf_buffer,
to_chars_buffer, output_length)' failed.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (25 preceding siblings ...)
2021-03-05 2:37 ` dje at gcc dot gnu.org
@ 2021-03-08 17:42 ` ppalka at gcc dot gnu.org
2021-03-08 17:53 ` schwab@linux-m68k.org
` (13 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-03-08 17:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #24 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to David Edelsohn from comment #23)
> The AIX failure is:
>
> printf_buffer=
> 1.
> 44269504088896338700465094007086008800000000000000000000000000000000000000000
> 00000000000000000000000
>
> to_chars_buffer=
> 1.
> 44269504088896338700465094007086008787155151367187500000000000000000000000000
> 00000000000000000000000??/?P00001.
> 44269504088896338700465094007086008800000000000000000000000000000000000000000
> 00000000000000000000000
>
> output_length=
> 102
>
> ./long_double.cc:194: void test02(): Assertion '!memcmp(printf_buffer,
> to_chars_buffer, output_length)' failed.
I managed to reproduce this issue on AIX (gcc119). It looks like the %e/%f/%g
specifiers (as well as %Le/%Lf/%Lg -- long double is equivalent to double)
never output more than 37 significant decimal digits on AIX.
For e.g.
printf("%.53e\n", 0x1.71547652b82fep+0);
printf("%.0f\n", 0x1.249ad2594c37dp+332);
x86 glibc printf outputs
1.44269504088896338700465094007086008787155151367187500e+00
10000000000000000159028911097599180468360808563945281389781327557747838772170381060813469985856815104
and AIX printf outputs
1.44269504088896338700465094007086008800000000000000000e+00
10000000000000000159028911097599180470000000000000000000000000000000000000000000000000000000000000000
It seems to me the output of AIX printf is wrong/nonconforming here..
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (26 preceding siblings ...)
2021-03-08 17:42 ` ppalka at gcc dot gnu.org
@ 2021-03-08 17:53 ` schwab@linux-m68k.org
2021-03-08 19:27 ` dje at gcc dot gnu.org
` (12 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: schwab@linux-m68k.org @ 2021-03-08 17:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #25 from Andreas Schwab <schwab@linux-m68k.org> ---
I don't think this is wrong, as long as DECIMAL_DIG <= 37.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (27 preceding siblings ...)
2021-03-08 17:53 ` schwab@linux-m68k.org
@ 2021-03-08 19:27 ` dje at gcc dot gnu.org
2021-03-08 21:09 ` iains at gcc dot gnu.org
` (11 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: dje at gcc dot gnu.org @ 2021-03-08 19:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #26 from David Edelsohn <dje at gcc dot gnu.org> ---
By default, long double on AIX is the same as double (64 bits). One optionally
can specify 128 bit long double and link with libc128.a to provide long double
stdio.
AIX float.h:
#define DECIMAL_DIG 37
I'm perfectly okay with libstdc++ skipping this test on AIX. I don't know how
you want to skip it. I would suggest
dg-require-effective-target longdouble128
Or you can skip the portions of the test that expect DECIMAL_DIG > 37.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (28 preceding siblings ...)
2021-03-08 19:27 ` dje at gcc dot gnu.org
@ 2021-03-08 21:09 ` iains at gcc dot gnu.org
2021-03-08 21:24 ` iains at gcc dot gnu.org
` (10 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: iains at gcc dot gnu.org @ 2021-03-08 21:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #27 from Iain Sandoe <iains at gcc dot gnu.org> ---
for Darwin x86
* the test at line 83 fails, and with some more debugging stuff inserted and
the abort removed, there are 66 cases where the strings do not agree, so a bug
in libc (probably) .. I'm doing seem more tests on a newer system version.
for Darwin PPC
* the tests don't build currently, because the new symbols need adding to the
library exports (patch incoming for that).
However, with the symbol fix, there's then a different fail (round-trip)
which I have yet to analyse.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (29 preceding siblings ...)
2021-03-08 21:09 ` iains at gcc dot gnu.org
@ 2021-03-08 21:24 ` iains at gcc dot gnu.org
2021-03-09 9:55 ` iains at gcc dot gnu.org
` (9 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: iains at gcc dot gnu.org @ 2021-03-08 21:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #28 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #27)
> for Darwin x86
>
> * the test at line 83 fails, and with some more debugging stuff inserted and
> the abort removed, there are 66 cases where the strings do not agree, so a
> bug in libc (probably) .. I'm doing seem more tests on a newer system
> version.
repeated on macOS11 (Darwin20) - the fails are for precisions 1, 5, 9 and 13
(if there's any significance to that) with a pattern that looks like this:
begin 9.2p-11003, printf_buffer 0x9.1p-11003
FAILED: prec has value 1
--
begin 9.1a2b4p-11003, printf_buffer 0x9.1a2b3p-11003
FAILED: prec has value 5
--
begin 9.1a2b3c4d6p-11003, printf_buffer 0x9.1a2b3c4d5p-11003
FAILED: prec has value 9
--
begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
FAILED: prec has value 13
--
begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
FAILED: prec has value 13
--
begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
FAILED: prec has value 13
(and similarly for the other values that fail, not read the code enough yet to
figure out why we get the three cases for 13...).
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (30 preceding siblings ...)
2021-03-08 21:24 ` iains at gcc dot gnu.org
@ 2021-03-09 9:55 ` iains at gcc dot gnu.org
2021-03-10 14:28 ` ppalka at gcc dot gnu.org
` (8 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: iains at gcc dot gnu.org @ 2021-03-09 9:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #29 from Iain Sandoe <iains at gcc dot gnu.org> ---
it seems that libc++ doesn't have support for long double to_chars yet, so I
couldn't do a comparison with the platform libc++.
However, I did build the code with clang (but using -stdlib=libstdc++, so the
headers and implementation are the same as for GCC) - but OTOH that does rule
out code-gen. (same result).
.. also checked feget/setround and it seems that the default is correct.
So.. most likely this is a libc problem, I guess (and not sure how to report it
at the moment, since there's no reproducer for the system compiler).
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (31 preceding siblings ...)
2021-03-09 9:55 ` iains at gcc dot gnu.org
@ 2021-03-10 14:28 ` ppalka at gcc dot gnu.org
2021-03-10 14:51 ` ppalka at gcc dot gnu.org
` (7 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-03-10 14:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #30 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Andreas Schwab from comment #25)
> I don't think this is wrong, as long as DECIMAL_DIG <= 37.
Ah, that's good to know, thanks. So that's yet another non-portable assumption
about printf made by this test... We can't rely on printf outputting a value
exactly if it has more than DECIMAL_DIG significant decimal digits.
On targets where long double == double, I suppose we can just skip this test.
On these targets, the long double to_chars overloads are defined as trivial
wrappers around the double overloads, so it should suffice to test just the
double overloads. This'll take care of FAIL on AIX.
And I think I'll XFAIL the test on Solaris and Darwin for now. (For GCC 12 I
should replace this non-portable test with a separate test for each supported
long double format in the style of float.cc/double.cc.)
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (32 preceding siblings ...)
2021-03-10 14:28 ` ppalka at gcc dot gnu.org
@ 2021-03-10 14:51 ` ppalka at gcc dot gnu.org
2021-04-08 15:11 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-03-10 14:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #31 from Patrick Palka <ppalka at gcc dot gnu.org> ---
(In reply to Iain Sandoe from comment #28)
> (In reply to Iain Sandoe from comment #27)
> > for Darwin x86
> >
> > * the test at line 83 fails, and with some more debugging stuff inserted and
> > the abort removed, there are 66 cases where the strings do not agree, so a
> > bug in libc (probably) .. I'm doing seem more tests on a newer system
> > version.
>
> repeated on macOS11 (Darwin20) - the fails are for precisions 1, 5, 9 and 13
> (if there's any significance to that) with a pattern that looks like this:
>
> begin 9.2p-11003, printf_buffer 0x9.1p-11003
> FAILED: prec has value 1
> --
> begin 9.1a2b4p-11003, printf_buffer 0x9.1a2b3p-11003
> FAILED: prec has value 5
> --
> begin 9.1a2b3c4d6p-11003, printf_buffer 0x9.1a2b3c4d5p-11003
> FAILED: prec has value 9
> --
> begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
> FAILED: prec has value 13
> --
> begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
> FAILED: prec has value 13
> --
> begin 9.1a2b3c4d5e6f8p-11003, printf_buffer 0x9.1a2b3c4d5e6f7p-11003
> FAILED: prec has value 13
>
> (and similarly for the other values that fail, not read the code enough yet
> to figure out why we get the three cases for 13...).
Thanks for digging into this! So it looks like the disagreement here is the
rounding of the least significant hexit. Assuming the FP rounding mode is set
to FE_TONEAREST, seems like a bug in printf indeed.. I can't think of any
reason why this happens only with precisions 1,5,9 and 13 and not also with
3,7,11.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (33 preceding siblings ...)
2021-03-10 14:51 ` ppalka at gcc dot gnu.org
@ 2021-04-08 15:11 ` cvs-commit at gcc dot gnu.org
2021-04-08 15:22 ` [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails ppalka at gcc dot gnu.org
` (5 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-08 15:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #32 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:
https://gcc.gnu.org/g:ca4641a3b536c9301a6dcb6cb2e26bd4717b47d9
commit r11-8055-gca4641a3b536c9301a6dcb6cb2e26bd4717b47d9
Author: Patrick Palka <ppalka@redhat.com>
Date: Thu Apr 8 11:10:58 2021 -0400
libstdc++: Address remaining to_chars/long_double.cc FAILs [PR98384]
This works around the remaining reported execution FAILs of this test on
AIX, Solaris and Darwin. Eventually we should rewrite this test to be
less fragile, but there's not enough time to do that for GCC 11.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Don't run the test
on targets without a large long double. XFAIL the execution on
targets with a non-conforming printf.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (34 preceding siblings ...)
2021-04-08 15:11 ` cvs-commit at gcc dot gnu.org
@ 2021-04-08 15:22 ` ppalka at gcc dot gnu.org
2021-04-08 16:22 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: ppalka at gcc dot gnu.org @ 2021-04-08 15:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Patrick Palka <ppalka at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[11 Regression] new test |new test case
|case |20_util/to_chars/long_doubl
|20_util/to_chars/long_doubl |e.cc in r11-6249 fails
|e.cc in r11-6249 fails on |
|powerpc64 BE |
--- Comment #33 from Patrick Palka <ppalka at gcc dot gnu.org> ---
After the above commit, all reported FAILs should now be addressed one way or
another so I'm removing the [11 Regression] marker.
I suppose we should keep the bug open as a reminder that the test is fragile
and could use rewriting.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (35 preceding siblings ...)
2021-04-08 15:22 ` [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails ppalka at gcc dot gnu.org
@ 2021-04-08 16:22 ` redi at gcc dot gnu.org
2021-04-27 11:39 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: redi at gcc dot gnu.org @ 2021-04-08 16:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P1 |P3
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (36 preceding siblings ...)
2021-04-08 16:22 ` redi at gcc dot gnu.org
@ 2021-04-27 11:39 ` jakub at gcc dot gnu.org
2021-07-28 7:05 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
40 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-04-27 11:39 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|11.0 |11.2
--- Comment #34 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.1 has been released, retargeting bugs to GCC 11.2.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (37 preceding siblings ...)
2021-04-27 11:39 ` jakub at gcc dot gnu.org
@ 2021-07-28 7:05 ` rguenth at gcc dot gnu.org
2022-04-21 7:48 ` rguenth at gcc dot gnu.org
2023-05-29 10:03 ` jakub at gcc dot gnu.org
40 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2021-07-28 7:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|11.2 |11.3
--- Comment #35 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.2 is being released, retargeting bugs to GCC 11.3
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (38 preceding siblings ...)
2021-07-28 7:05 ` rguenth at gcc dot gnu.org
@ 2022-04-21 7:48 ` rguenth at gcc dot gnu.org
2023-05-29 10:03 ` jakub at gcc dot gnu.org
40 siblings, 0 replies; 42+ messages in thread
From: rguenth at gcc dot gnu.org @ 2022-04-21 7:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|11.3 |11.4
--- Comment #36 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 11.3 is being released, retargeting bugs to GCC 11.4.
^ permalink raw reply [flat|nested] 42+ messages in thread* [Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails
2020-12-18 21:39 [Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE seurer at gcc dot gnu.org
` (39 preceding siblings ...)
2022-04-21 7:48 ` rguenth at gcc dot gnu.org
@ 2023-05-29 10:03 ` jakub at gcc dot gnu.org
40 siblings, 0 replies; 42+ messages in thread
From: jakub at gcc dot gnu.org @ 2023-05-29 10:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|11.4 |11.5
--- Comment #37 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 11.4 is being released, retargeting bugs to GCC 11.5.
^ permalink raw reply [flat|nested] 42+ messages in thread