https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127980
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2026-10-19
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Spencer Williams from comment #0)
> Upstream fast_float fixed exactly this in
> https://github.com/fastfloat/fast_float/pull/408 (merged 2026-09-22) by
> applying the normal branch's round-to-even test in the subnormal branch too.
Yes, this is already on our radar.
> A re-sync of fast_float alone will not fix libstdc++, because libstdc++'s
> float16 support is its own wrapper (floating_type_float16_t in
> src/c++17/floating_from_chars.cc), not upstream's std::float16_t
> specialization. The fix needs both:
>
> 1. the subnormal round-to-even test from fast_float#408 in compute_float()
> (upstream gates it on binary_format<T>::subnormal_ties_possible(), which
> is derived from the format's constants and already comes out true for
> floating_type_float16_t), and
> 2. binary_format<floating_type_float16_t>::min_exponent_round_to_even()
> widened from -22 to -26, as upstream did for its float16_t, since the
> subnormal ties need q = -25 and q = -26. Without this, the check in (1)
> is never reached for these inputs.
Aha, thanks.
