[libc-commits] [PATCH] D134917: [libc] Resolve NaN/implementation-defined behavior of floating-point tests

Michael Jones via Phabricator via libc-commits libc-commits at lists.llvm.org
Fri Sep 30 13:36:43 PDT 2022


michaelrj added inline comments.


================
Comment at: libc/src/__support/FPUtil/FPBits.h:94
+  static constexpr int EXPONENT_BIAS =
+      (UIntType(1) << (ExponentWidth<T>::VALUE - 1)) - 1;
+  static constexpr int MAX_EXPONENT =
----------------
if you're going to make these UIntType then you should change the variable to be UIntType as well, but that shouldn't be necessary as the largest float we need to handle is quadruple precision which uses 15 bits for its exponent, and int is defined as being at least 16 bits.


================
Comment at: libc/src/__support/FPUtil/FPBits.h:182
     FPBits<T> bits = inf();
-    bits.set_mantissa(v);
+    bits.set_mantissa(QUIET_BIT | v);
     return T(bits);
----------------
this would make it impossible to generate a signaling NaN with this function, since it would always set the quiet bit. Currently the expectation is that the client code will pass a mantissa with the quiet bit set iff the resulting NaN should be quiet.


================
Comment at: libc/test/src/math/RoundToIntegerTest.h:87
     test_one_input(func, neg_inf, INTEGER_MIN, true);
+#ifndef LLVM_LIBC_NO_IMPLEMENTATION_DEFINED_TEST_BEHAVIOR
+    // Result is not well-defined, we always returns INTEGER_MAX
----------------
is this flag set anywhere?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134917/new/

https://reviews.llvm.org/D134917



More information about the libc-commits mailing list