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