https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384
--- Comment #18 from Patrick Palka <ppalka at gcc dot gnu.org> ---
FWIW, here's a complete corrected version of the Solaris test in comment #13
which should be fully free of warnings:
#include <cstdio>
int main() {
printf("%La\n", 1.0L); // trailing zeros present (not nonconforming, but
unexpected by the libstdc++ testcase)
printf("%.1000Lf\n", 1.0L); // output contains e+00 (nonconforming?)
printf("%Lf\n", 1e1000L); // output is in scientific notation
(nonconforming?)
}
(In reply to Iain Sandoe from comment #17)
> (In reply to Patrick Palka from comment #16)
> > (In reply to r...@cebitec.uni-bielefeld.de from comment #14)
> > > > --- Comment #13 from Patrick Palka <ppalka at gcc dot gnu.org> ---
>
> [..]
> > > Which according to ISO C 2017, p.228, is allowed: "trailing zeros may
> > > be omitted".
> >
> > Ack.
>
> Darwin also produces the trailing zeros.
>
> For the #c13 test with Jakub's correction (x86_64-darwin16):
>
> 0x8p-3
Thanks. Trailing zeros in the second line of output are expected (and
required). It's the hex form (on the first line of output) that the libstdc++
testcase doesn't expect to contain trailing zeros, so I don't anticipate any
issues with printf on Darwin. So my hope is that the
https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565726.html resolves
the long_double.cc FAIL on 64-bit Darwin as well.
