[Bug target/111709] [13/14/15 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c since r13-1268-g8c99e307b20c50

[danglin at gcc dot gnu.org]

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.