These warning were identified while debugging modules with Wsystem-headers.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Will do.
libcxx/include/atomic | ||
---|---|---|
2694 | Yeah, not sure whether we want to unconditionally undef or do ifdef here. | |
libcxx/include/cmath | ||
534–535 | warning: implicit conversion loses floating-point precision: 'double' to 'float' [-Wimplicit-float-conversion] inline _LIBCPP_INLINE_VISIBILITY float hypot( float x, float y, float z ) { return sqrt(x*x + y*y + z*z); } ~~~~~~ ^~~~~~~~~~~~~~~~~~~~~ | |
libcxx/include/string_view | ||
288 | Will do. |
libcxx/include/string_view | ||
---|---|---|
288 | Hmm looks like numeric_limits just moves the problem: warning: signed shift result (0x8000000000000000) sets the sign bit of the shift expression's type ('long') and becomes negative [-Wshift-sign-overflow] static _LIBCPP_CONSTEXPR const _Tp value = _Tp(_Tp(1) << __digits); Two alternatives come to mind; either we suppress the warning here, or we do something similar to the following (for e.g. int64_t): -static_cast<uint64_t>((1ULL << (sizeof(int64_t) * CHAR_BITS - 1) - 1) |
libcxx/include/cmath | ||
---|---|---|
534–535 | I'm not quite sure whats going on here, I get a bunch of these even with my changes: warning: implicit conversion loses floating-point precision: 'double' to 'float' [-Wimplicit-float-conversion] inline _LIBCPP_INLINE_VISIBILITY float hypot( float __x, float __y, float __z ) { return sqrt(__x*__x + __y*__y + __z*__z); } ~~~~~~ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ warning: implicit conversion increases floating-point precision: 'float' to 'double' [-Wdouble-promotion] inline _LIBCPP_INLINE_VISIBILITY float hypot( float __x, float __y, float __z ) { return sqrt(__x*__x + __y*__y + __z*__z); } |
libcxx/utils/libcxx/test/params.py | ||
---|---|---|
21 | Don't think I can make this change yet. There's other related warnings: atomic: warning: implicit conversion changes signedness: 'std::__memory_order_underlying_t' (aka 'unsigned int') to 'int' [-Wsign-conversion] __c11_atomic_signal_fence(static_cast<__memory_order_underlying_t>(__order)); I don't quite understand this bit, there's some comments about conditional behavior under _LIBCPP_STD_VER > 17 |
We're moving to GitHub PRs it would be great when this patch can be finished before moving. Are you interested in finishing it? If not I'll take over. Please start by rebasing the patch to see whether it passes the CI.
Is this because ATOMIC_FLAG_INIT was already defined by the C Library?