[libc-commits] [libc] [libc][math][c23] Add f16divf C23 math function (PR #96131)

[via libc-commits]

================
@@ -179,10 +182,18 @@ template <size_t Bits> struct DyadicFloat {
       output_bits_t clear_exp = static_cast<output_bits_t>(
           output_bits_t(exp_hi) << FPBits<T>::SIG_LEN);
       output_bits_t r_bits = FPBits<T>(r).uintval() - clear_exp;
+
       if (!(r_bits & FPBits<T>::EXP_MASK)) {
         // Output is denormal after rounding, clear the implicit bit for 80-bit
         // long double.
         r_bits -= IMPLICIT_MASK;
+
+        // TODO: IEEE Std 754-2019 lets implementers choose whether to check for
+        // "tininess" before or after rounding for base-2 formats, as long as
+        // the same choice is made for all operations. Our choice to check after
+        // rounding might not be the same as the hardware's.
+        if (round_and_sticky)
+          raise_except_if_required(FE_UNDERFLOW);
----------------
overmighty wrote:

Oops, I missed this comment.

IEEE Std 754-2019 section "7.5 Underflow":

> The underflow exception shall be signaled when a tiny non-zero result is detected. For binary formats, this
> shall be either:
> 
> a) *after rounding*—when a non-zero result computed as though the exponent range were unbounded
> would lie strictly between ± *b^emin*, or
> b) *before rounding*—when a non-zero result computed as though both the exponent range and the
> precision were unbounded would lie strictly between ± *b^emin* .
> 
> The implementer shall choose how tininess is detected, but shall detect tininess in the same way for all
> operations in radix two, including conversion operations under a binary rounding attribute.

However:

> In addition, under default exception handling for underflow, if the rounded result is inexact—that is, it
> differs from what would have been computed were both exponent range and precision unbounded—the
> underflow flag shall be raised and the inexact (see 7.6) exception shall be signaled. **If the rounded result is
> exact, no flag is raised and no inexact exception is signaled.** This is the only case in this standard of an
> exception signal receiving default handling that does not raise the corresponding flag. **Such an underflow
> signal has no observable effect under default handling.**

Emphasis mine.


https://github.com/llvm/llvm-project/pull/96131