[libc] fix error: implicit conversion loses floating-point precision: 'double' to 'float' in shared_math_test.cpp

[makslevental]

This test fails under -Werror=implicit-float-conversion (like in our pre-merge CI) because dsqrtl returns a double

llvm-project/libc/src/__support/math/dsqrtl.h

Line 18 in 2b937da

LIBC_INLINE static constexpr double dsqrtl(long double x) {

Fixes #159932

[llvmbot]

@llvm/pr-subscribers-libc

Author: Maksim Levental (makslevental)

Changes

This test fails under -Werror=implicit-float-conversion (like in our pre-merge CI) because dsqrtl returns a double

llvm-project/libc/src/__support/math/dsqrtl.h

Line 18 in 2b937da

LIBC_INLINE static constexpr double dsqrtl(long double x) {

Fixes #159932

---

Full diff: https://github.com/llvm/llvm-project/pull/159934.diff

1 Files Affected:

• (modified) libc/test/shared/shared_math_test.cpp (+1-1)

diff --git a/libc/test/shared/shared_math_test.cpp b/libc/test/shared/shared_math_test.cpp
index 9e4d4d52e7f5e..bfff5ecb8cf81 100644
--- a/libc/test/shared/shared_math_test.cpp
+++ b/libc/test/shared/shared_math_test.cpp
@@ -57,7 +57,7 @@ TEST(LlvmLibcSharedMathTest, AllFloat) {
   EXPECT_FP_EQ(0x1p+0f, LIBC_NAMESPACE::shared::cosf(0.0f));
   EXPECT_FP_EQ(0x1p+0f, LIBC_NAMESPACE::shared::coshf(0.0f));
   EXPECT_FP_EQ(0x1p+0f, LIBC_NAMESPACE::shared::cospif(0.0f));
-  EXPECT_FP_EQ(0x0p+0f, LIBC_NAMESPACE::shared::dsqrtl(0.0f));
+  EXPECT_FP_EQ(0x0p+0f, (float)LIBC_NAMESPACE::shared::dsqrtl(0.0f));
   EXPECT_FP_EQ(0x0p+0f, LIBC_NAMESPACE::shared::erff(0.0f));
   EXPECT_FP_EQ(0x1p+0f, LIBC_NAMESPACE::shared::exp10f(0.0f));
   EXPECT_FP_EQ(0x1p+0f, LIBC_NAMESPACE::shared::expf(0.0f));

[makslevental]

Note, I'm not sure if this is the right - the alternative could be

EXPECT_FP_EQ(0x0p+0, LIBC_NAMESPACE::shared::dsqrtl(0.0));

but all the values in this test are single 🤷.

[jhuber6]

Either just use the double constant without the f or use a C++ cast.

[makslevental]

done

[jhuber6]

If it fixes the warning without the f constant then that's probably the better solution, since technically the double result could be outisde a float's ULP and get rounded to zero. Though the chances of that happening are quite slim.

[makslevental]

done

[lntue]

Note, I'm not sure if this is the right - the alternative could be

EXPECT_FP_EQ(0x0p+0, LIBC_NAMESPACE::shared::dsqrtl(0.0));

but all the values in this test are single 🤷.

The input should be 0.0L and the output should be 0.0