On Mon, 17 Oct 2022 at 22:33, Joseph Myers <jos...@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.
