[Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[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]

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

            Bug ID: 98384
           Summary: new test case 20_util/to_chars/long_double.cc in
                    r11-6249 fails on powerpc64 BE
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:3c57e692357c79ee7623dfc1586652aee2aefb8f, r11-6249

make  -k check RUNTESTFLAGS="conformance.exp=20_util/to_chars/long_double.cc"
FAIL: 20_util/to_chars/long_double.cc (test for excess errors)
# of unexpected failures        1
# of unresolved testcases       1

commit 3c57e692357c79ee7623dfc1586652aee2aefb8f
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Dec 17 23:11:34 2020 -0500

    libstdc++: Add floating-point std::to_chars implementation

This new test case is failing on powerpc64 big endian machines.  It works fine
on LE machines.

/home/seurer/gcc/git/build/gcc-test/./gcc/xg++ -shared-libgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
-include bits/stdc++.h -fdiagnostics-plain-output ./libtestc++.a
-Wl,--gc-sections
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs
-lm -o ./long_double.exe
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:
In function 'void test01()':
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:42:
error: 'nextdownl' was not declared in this scope; did you mean 'nexttowardl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:43:
error: 'nextupl' was not declared in this scope; did you mean 'expl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:
In function 'void test02()':
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:175:
error: 'nextdownl' was not declared in this scope; did you mean 'nexttowardl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:184:
error: 'nextupl' was not declared in this scope; did you mean 'expl'?
compiler exited with status 1
FAIL: 20_util/to_chars/long_double.cc (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:42:
error: 'nextdownl' was not declared in this scope; did you mean 'nexttowardl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:43:
error: 'nextupl' was not declared in this scope; did you mean 'expl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:175:
error: 'nextdownl' was not declared in this scope; did you mean 'nexttowardl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:184:
error: 'nextupl' was not declared in this scope; did you mean 'expl'?

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ro at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[rguenth at gcc dot gnu.org]

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

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[iains at gcc dot gnu.org]

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).

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[iains at gcc dot gnu.org]

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).

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[cvs-commit at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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?

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[rguenth at gcc dot gnu.org]

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

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[jakub at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[cvs-commit at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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 :)

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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?

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ro at CeBiTec dot Uni-Bielefeld.DE]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[jakub at gcc dot gnu.org]

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?

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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 :)

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[iains at gcc dot gnu.org]

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

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[cvs-commit at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[iains at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[dje at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[dje at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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..

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[schwab@linux-m68k.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[dje at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[iains at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[iains at gcc dot gnu.org]

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...).

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[iains at gcc dot gnu.org]

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).

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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.)

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ppalka at gcc dot gnu.org]

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.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[cvs-commit at gcc dot gnu.org]

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.

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails

[ppalka at gcc dot gnu.org]

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.

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails

[redi at gcc dot gnu.org]

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

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails

[jakub at gcc dot gnu.org]

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.

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails

[rguenth at gcc dot gnu.org]

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

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails

[rguenth at gcc dot gnu.org]

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.

[Bug libstdc++/98384] new test case 20_util/to_chars/long_double.cc in r11-6249 fails

[jakub at gcc dot gnu.org]

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.