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