Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libc/src/__support/FPUtil/FPBits.h | ||
---|---|---|
95 | 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. | |
169 | 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. | |
libc/test/src/math/RoundToIntegerTest.h | ||
87 | is this flag set anywhere? |
libc/src/__support/FPUtil/FPBits.h | ||
---|---|---|
169 | It's probably better to add another method called build_quiet_nan and leave build_nan to create signaling nan if needed? Most of build_nan usage in src/math folder then can simply be replaced with build_quiet_nan. |
libc/src/__support/FPUtil/FPBits.h | ||
---|---|---|
174 | I think you meant to call build_nan. Otherwise this is an infinite recursion. |
libc/utils/UnitTest/FPMatcher.h | ||
---|---|---|
75 | the build failures were caused by this line. Changing it back to build_nan fixes the issue. Maybe add qNaN as an additional variable for quiet NaN purposes. |
libc/utils/UnitTest/FPMatcher.h | ||
---|---|---|
75 | Look like the failures are actually in the implementation and tests of atanf and atanhf. According to the spec, we should not set floating point exceptional flags when the input is NaN, signaling or quiet. You can change the atanf_test and atanhf_test to EXPECT_FP_EXCEPTION(0); for aNaN inputs and simply return x in atanf.cpp and atanhf.cpp for NaN inputs instead of x + 1.0f as of now. |
libc/utils/UnitTest/FPMatcher.h | ||
---|---|---|
75 | Thanks for the help! Is there an easy way to rerun the test? ninja check-llvmlibc only works once. |
libc/utils/UnitTest/FPMatcher.h | ||
---|---|---|
75 | Normally I would simply $ touch <test_files> or $ touch <source_files>, and then simply run the test directly with $ ninja libc.test.src.math.<test>, unless the changes are in CMakeFiles.txt |
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.