https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #13 from Patrick Palka <ppalka at gcc dot gnu.org> --- (In reply to r...@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?
