[libc-commits] [libc] [libc][math] Update getpayload and fmul with NaN inputs. (PR #99812)
via libc-commits
libc-commits at lists.llvm.org
Sun Jul 21 14:44:48 PDT 2024
================
@@ -38,23 +38,8 @@ class MulTest : public LIBC_NAMESPACE::testing::FEnvSafeTest {
EXPECT_FP_IS_NAN_WITH_EXCEPTION(func(sNaN, sNaN), FE_INVALID);
InType qnan_42 = InFPBits::quiet_nan(Sign::POS, 0x42).get_val();
- EXPECT_FP_EQ(InType(0x42.0p+0),
- LIBC_NAMESPACE::fputil::getpayload(func(qnan_42, zero)));
- EXPECT_FP_EQ(InType(0x42.0p+0),
- LIBC_NAMESPACE::fputil::getpayload(func(zero, qnan_42)));
-
- if constexpr (sizeof(OutType) < sizeof(InType)) {
- InStorageType max_payload = InFPBits::FRACTION_MASK >> 1;
- InType qnan_max = InFPBits::quiet_nan(Sign::POS, max_payload).get_val();
- EXPECT_FP_EQ(zero,
- LIBC_NAMESPACE::fputil::getpayload(func(qnan_max, zero)));
- EXPECT_FP_EQ(zero,
- LIBC_NAMESPACE::fputil::getpayload(func(zero, qnan_max)));
- EXPECT_FP_EQ(InType(0x42.0p+0),
- LIBC_NAMESPACE::fputil::getpayload(func(qnan_max, qnan_42)));
- EXPECT_FP_EQ(InType(0x42.0p+0),
- LIBC_NAMESPACE::fputil::getpayload(func(qnan_42, qnan_max)));
- }
+ EXPECT_FP_IS_NAN(func(qnan_42, zero));
+ EXPECT_FP_IS_NAN(func(zero, qnan_42));
----------------
lntue wrote:
Yes, I don't think we need to be that strict on NaN propagation when it is underspecified in the standards, as long as the NaN semantic is preserved.
https://github.com/llvm/llvm-project/pull/99812
More information about the libc-commits
mailing list