HPX: Suppress -Wmaybe-uninitialized #8017
Conversation
I tried that now: |
|
Try #pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wunknown-warning-option"
#pragma GCC diagnostic ignored "-Wmaybe-uninitialized" |
4c5ec82 to
c24d6d7
Compare
Signed-off-by: Daniel Arndt <arndtd@ornl.gov>
This reverts commit 1ed1d17. Signed-off-by: Daniel Arndt <arndtd@ornl.gov>
Signed-off-by: Daniel Arndt <arndtd@ornl.gov>
c24d6d7 to
476bcdb
Compare
|
We need different suppressions for the compiler, |
There was a problem hiding this comment.
Ok I don't like the BasicView thing either, but I guess the only alternatives are turning the unused variable warning globally off for the HPX build, or turn warnings as error off for the HPX build. Given these options I guess I am ok with the push pop in BasicView. But I think the condition at the bottom is wrong or?
| @@ -619,6 +629,11 @@ class BasicView { | |||
| template <class, class, class, class> | |||
| friend class BasicView; | |||
| }; | |||
|
|
|||
| #if defined(KOKKOS_ENABLE_HPX) && !defined(__clang__) | |||
| #pragma GCC diagnostic pop | |||
There was a problem hiding this comment.
doesn't this need to happen independent of clang? The diagnostic push up there is just dependent on HPX?
| // FIXME_HPX spurious warnings like | ||
| // error: 'SR.14123' may be used uninitialized [-Werror=maybe-uninitialized] | ||
| #if defined(KOKKOS_ENABLE_HPX) | ||
| #pragma GCC diagnostic push | ||
| #if !defined(__clang__) | ||
| #pragma GCC diagnostic ignored "-Wmaybe-uninitialized" | ||
| #endif | ||
| #pragma GCC diagnostic ignored "-Wuninitialized" | ||
| #endif | ||
|
|
There was a problem hiding this comment.
I managed to reproduce this with just the serial backend enabled over here: https://github.com/msimberg/kokkos/actions/runs/14673110353/job/41184658454#step:10:343 (note that on the log posted in the PR description the error is also triggered from a serial backend test). It's otherwise the same as the HPX configuration, so it's likely something from the fedora image that's triggering it compared to the other serial CI configuration (there are a few other differences, not sure which are relevant)?
| : m_instance_data(Kokkos::Impl::HostSharedPtr<instance_data>( | ||
| &m_default_instance_data, &default_instance_deleter)) {} |
There was a problem hiding this comment.
I did a few small tests, and one of the other things that silences the warning is initializing m_instance_data inside the body of the constructor. I think this points to the warning indeed being bogus. I'm thinking perhaps the static analyzer gets confused by the throwing execution path of HostSharedPtr or something like that?
In any case, I think, if this is indeed a false positive, the #pragma GCC diagnostic ignored is in my opinion clearer than e.g. moving the initialization to the constructor body (or another code change that silences the warning).
I'd prefer to just get our CI running again for now and investigate that in a follow-up. Compiling with |
There was a problem hiding this comment.
Since this basically passed testing: I am ok merging it, but Daniel open a follow on PR to take away the #ifdef HPX. Since this reproduces with Serial only it seems a general issue. I am not convinced that it's worth it to spend 20 hours tracking down exactly which GCC version/header library or what not triggers it. If other people feel differently I will assign someone.
Yes, but only after updating the toolchain. Technically, we compile with |
Yes, the warning isn't very helpful but we haven't found anything obvious. |
We will follow-up on the cause and possibly suppress the warning for more backends.
|
@hkaiser Any remarks with respect to HPX? |
|
I gonna merge, and we need to figure out what exact condition we need for the push in a follow on. As it was pointed out it's NOT HPX, but rather depending on some toolchain specific stuff. But that will likely take a few days and we need to get our CI working. |
I was able to reproduce the errors linked in the source code, e.g., https://github.com/kokkos/kokkos/actions/runs/14537421172/job/40793403561 but don't have a better idea than to suppress for now.