libstdc++: Add floating-point std::to_chars implementation

This implements the floating-point std::to_chars overloads for float,
double and long double.  We use the Ryu library to compute the shortest
round-trippable fixed and scientific forms for float, double and long
double.  We also use Ryu for performing explicit-precision fixed and
scientific formatting for float and double. For explicit-precision
formatting for long double we fall back to using printf.  Hexadecimal
formatting for float, double and long double is implemented from
scratch.

The supported long double binary formats are binary64, binary80 (x86
80-bit extended precision), binary128 and ibm128.

Much of the complexity of the implementation is in computing the exact
output length before handing it off to Ryu (which doesn't do bounds
checking).  In some cases it's hard to compute the output length
beforehand, so in these cases we instead compute an upper bound on the
output length and use a sufficiently-sized intermediate buffer only if
necessary.

Another source of complexity is in the general-with-precision formatting
mode, where we need to do zero-trimming of the string returned by Ryu,
and where we also take care to avoid having to format the number through
Ryu a second time when the general formatting mode resolves to fixed
(which we determine by doing a scientific formatting first and
inspecting the scientific exponent).  We avoid going through Ryu twice
by instead transforming the scientific form to the corresponding fixed
form via in-place string manipulation.

This implementation is non-conforming in a couple of ways:

1. For the shortest hexadecimal formatting, we currently follow the
   Microsoft implementation's decision to be consistent with the
   output of printf's '%a' specifier at the expense of sometimes not
   printing the shortest representation.  For example, the shortest hex
   form for the number 1.08p+0 is 2.1p-1, but we output the former
   instead of the latter, as does printf.

2. The Ryu routine generic_binary_to_decimal that we use for performing
   shortest formatting for large floating point types is implemented
   using the __int128 type, but some targets with a large long double
   type lack __int128 (e.g. i686), so we can't perform shortest
   formatting of long double on such targets through Ryu.  As a
   temporary stopgap this patch makes the long double to_chars overloads
   just dispatch to the double overloads on these targets, which means
   we lose precision in the output.  (We could potentially fix this by
   writing a specialized version of Ryu's generic_binary_to_decimal
   routine that uses uint64_t instead of __int128.)  [Though I wonder if
   there's a better way to work around the lack of __int128 on i686
   specifically?]

3. Our shortest formatting for __ibm128 doesn't guarantee the round-trip
   property if the difference between the high- and low-order exponent
   is large.  This is because we treat __ibm128 as if it has a
   contiguous 105-bit mantissa by merging the mantissas of the high-
   and low-order parts (using code extracted from glibc), so we
   potentially lose precision from the low-order part.  This seems to be
   consistent with how glibc printf formats __ibm128.

libstdc++-v3/ChangeLog:

	* config/abi/pre/gnu.ver: Add new exports.
	* include/std/charconv (to_chars): Declare the floating-point
	overloads for float, double and long double.
	* src/c++17/Makefile.am (sources): Add floating_to_chars.cc.
	* src/c++17/Makefile.in: Regenerate.
	* src/c++17/floating_to_chars.cc: New file.
	(to_chars): Define for float, double and long double.
	* testsuite/20_util/to_chars/long_double.cc: New test.

1 files changed, 1 insertions, 0 deletions

diff --git a/libstdc++-v3/src/c++17/Makefile.am b/libstdc++-v3/src/c++17/Makefile.am
index 37cdb53c076..2ec5ed621ca 100644
--- a/libstdc++-v3/src/c++17/Makefile.am
+++ b/libstdc++-v3/src/c++17/Makefile.am
@@ -51,6 +51,7 @@ endif
 
 sources = \
 	floating_from_chars.cc \
+	floating_to_chars.cc \
 	fs_dir.cc \
 	fs_ops.cc \
 	fs_path.cc \