[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

[ro at CeBiTec dot Uni-Bielefeld.DE]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98384

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- 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".

> 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);
      |          ^~~~~~~~~~~~

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.