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