-
Notifications
You must be signed in to change notification settings - Fork 226
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clang issues many -Wimplicit-int-float-conversion warnings from round, trunc etc #430
Comments
I can't speak for the authors of the code but here may be some subtle issues with numbers here at the outer reaches of the math/include/boost/math/special_functions/round.hpp Lines 113 to 121 in 5a1a302
Let's follow the logic of the warning and say that Based on the foregoing analysis, I'd say the warnings are legitimate and likely merit additional attention. The test code does appear to cover the long long max case – but it could be falling into the trap of comparing the undefined integer result of the function with the same undefined test value ( |
See also #435 |
This should be resolved by PR #474 |
Found another instance stemming from beta:
|
@evanmiller was entirely correct. The warnings were legitimate and it was a mistake to silence them with static casts.
All functions which convert integers max values to floating point are broken. int64_t max value can't be represented as a double. This code is incorrect: Here is a failing test case https://godbolt.org/z/G7nrP9nox :
This program prints:
Also an important fun fact: if the input is known at compile time then the above test incorrectly passes (change to |
Interestingly we are getting the same result as the STL https://godbolt.org/z/Ev4ManrsW. This also does not impact ARM systems because my M1 Mac properly returns |
@mborland this also seems to fix the issue, and is much simpler:
It would be nice to make I also note that itrunc/lltrunc will presumably have the same issue, possibly also the overloads of these functions in Boost.Multiprecision - though those are much less likely to have too little precision to accurately hold a long long. |
|
Yes, but isn't this where it gets tricky? We can't declare a variable that the result of ccmath::ldexp is assigned to as constexpr unless we know in advance that type T is capable of that. |
I'm hopeful it can be macro enabled instead of dispatching through enable if. I'll play with it. |
I appreciate that you were able to look at this so quickly, it is awesome. Thank you for this effort. Regarding the result from STL: apparently And regarding the M1: can you try with 9223372036854775808.0 ? (8 instead of 7 in the last place, this is equal to int64_max + 1). It should not be rounded down to ...7. Also try changing the variable to volatile. The compiler does something weird if the constants are known. For example, see the above godbolt link. change |
Suggested test case, avoids accidental const-propogation and checks both sides of the boundary.
|
Running the Boost.math tests using Clang10.0.0, I note many warnings from all uses of round, trunc (and others?).
In file included from ..\..\..\boost/math/concepts/real_concept.hpp:28: ..\..\..\boost/math/special_functions/round.hpp:118:12: warning: implicit conversion from 'long long' to 'long double' changes value from 9223372036854775807 to 9223372036854775808 [-Wimplicit-int-float-conversion] if((r > (std::numeric_limits<boost::long_long_type>::max)()) || (r < (std::numeric_limits<boost::long_long_type>::min)())) ~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Warnings only with Clang, not GCC nor MSVC, but the very many warning are cluttering the log files.
Should I deal with this by quieting the warning, perhaps by adding
<toolset>clang:<cxxflags>-Wno-implicit-int-float-conversion
to the /test jamfile?
Or is there some more subtle change required?
The text was updated successfully, but these errors were encountered: