[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" <gcc-bugzilla@gcc.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?