https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709
--- Comment #21 from John David Anglin <danglin at gcc dot gnu.org> --- For the testcase in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709#c16, the underflow bit is generated in this glibc code in s_fma.c: /* v.ieee.mantissa1 & 2 is LSB bit of the result before rounding, v.ieee.mantissa1 & 1 is the round bit and j is our sticky bit. */ w.d = 0.0; w.ieee.mantissa1 = ((v.ieee.mantissa1 & 3) << 1) | j; w.ieee.negative = v.ieee.negative; v.ieee.mantissa1 &= ~3U; v.d *= 0x1p-108; w.d *= 0x1p-2; return v.d + w.d; Before the multiplication, w is $4 = {d = -3.4584595208887258e-323, ieee = {negative = 1, exponent = 0, mantissa0 = 0, mantissa1 = 7}, ieee_nan = {negative = 1, exponent = 0, quiet_nan = 0, mantissa0 = 0, mantissa1 = 7}} After the multiplaction by 0x1p-2 (0.25), w is $3 = {d = -4.9406564584124654e-324, ieee = {negative = 1, exponent = 0, mantissa0 = 0, mantissa1 = 1}, ieee_nan = {negative = 1, exponent = 0, quiet_nan = 0, mantissa0 = 0, mantissa1 = 1}} and the inexact and underflow bits are set on hppa. The result looks reasonable to me. I'm not sure about ieee754 but different values can be returned when a non-trapping underflow occurs. So, the above code seems suspect. Maybe underflow and inexact should be cleared after w.d is multiplied by 0x1p-2? Given the difference between gcc-12 and gcc-13, I'm not sure the return paths are the same.
