Re: [RFC PATCH] libstdc++, v2: Partial library support for std::float{16, 32, 64, 128}_t

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Mon, 17 Oct 2022 at 22:33, Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 17 Oct 2022, Jonathan Wakely via Gcc-patches wrote:
>
> > > And I/O etc. support is missing, not sure I'm able to handle that and if it
> > > is e.g. possible to keep that support out of libstdc++.so.6, because what
> > > extended floating point types one has on a particular arch could change over
> > > time (I mean e.g. bfloat16_t support or float16_t support can be added
> > > etc.).
> >
> > Yes, I think we can add the I/O functions as always_inline because all
> > they're going to do is convert the argument to float, double, or long
> > double and then call the existing overloads. There will be no new
> > virtual functions.
>
> As with fma, note that doing conversions from strings to floating-point is
> a case where doing the operation on float and then narrowing is
> technically incorrect because double rounding can occur (the rounded float
> result can be half way between two values of the narrower type, without
> that being the exact mathematical result) but the operation should be
> correctly rounding.  It's fine to use float or double operations in the
> other direction (floating-point to strings), of course.

Yes, this is called out in the C++23 draft:

[ Note: When the extended floating-point type has a floating-point
conversion rank that is not equal to the rank of any standard
floating-point type, then double rounding during the conversion can
result in inaccurate results. from_chars can be used in situations
where maximum accuracy is important. - end note ]

The alternative is an ABI break, which we didn't want to force on
implementors. For libstdc++ we're not going to break the ABI, so we're
going to live with the double rounding.