https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120547
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <ja...@gcc.gnu.org>: https://gcc.gnu.org/g:ea9ea72e448e391d4be781b74956a0190f93afc8 commit r16-1185-gea9ea72e448e391d4be781b74956a0190f93afc8 Author: Jakub Jelinek <ja...@redhat.com> Date: Thu Jun 5 15:47:19 2025 +0200 real: Fix up real_from_integer [PR120547] The function has 2 problems, one is _BitInt specific and the other is most likely also reproduceable only with it. The first issue is that I've missed updating the function for _BitInt, maxbitlen as MAX_BITSIZE_MODE_ANY_INT + HOST_BITS_PER_WIDE_INT obviously isn't guaranteed to be larger than any integral type we might want to convert at compile time from wide_int to REAL_VALUE_FORMAT. Just using len instead of it works fine, at least when used after HOST_BITS_PER_WIDE_INT is added to it and it is truncated to multiples of HOST_BITS_PER_WIDE_INT. The other bug is that if the value has too many significant bits (formerly maxbitlen - cnt_l_z, now len - cnt_l_z), the code just shifts it right and adds the shift count to the future exponent. That isn't correct for rounding as the testcase attempts to show, the internal real format has more bits than any precision in supported format, but we still need to distinguish bewtween values exactly half way between representable floating point values (those should be rounded to even) and the case when we've shifted away some non-zero bits, so the value was tiny bit larger than half way and then we should round up. The patch uses something like e.g. soft-fp uses in these cases, right shift with sticky bit in the least significant bit. 2025-06-05 Jakub Jelinek <ja...@redhat.com> PR middle-end/120547 * real.cc (real_from_integer): Remove maxbitlen variable, use len instead of that. When shifting right, or in 1 if any of the shifted away bits are non-zero. Formatting fix. * gcc.dg/bitint-123.c: New test.
