Phil Miller - NOAA
Phil Miller - NOAA
The broader point is that the need for shared memory is an inherent property of any given piece of source code, not an environment. Going forward, we should require developers...
I think the helper functions are a big improvement
Here's a weird edge case to consider - should we accept copies from a strided view to a suitably padded view, such that a contiguous `memcpy` would not overwrite any...
> Does this also work with the other View-like types (`DualView`, `DynamicView`, `DynRankView`, `OffsetView`)? `DynRankView` should be happy with whatever we do for `View`, since `deep_copy` calls on it just...
UniversalMoving sounds fine to me. UniversalPinned is more troublesome, because either or both of host or device pinned could exist, and with different properties on both performance and non-compute accessibility
> One disadvantage of this approach would be that using different compilers for Kokkos and downstream applications causes issues when using `OpenMP` since the compiler flags for the found target...
The prior code in `Kokkos_Core.cpp` accepted `on`: ```c++ char* env_disablewarnings_str = std::getenv("KOKKOS_DISABLE_WARNINGS"); if (env_disablewarnings_str != nullptr) { std::string env_str(env_disablewarnings_str); // deep-copies string for (char& c : env_str) { c =...
And that was there prior to the 3.6 release
Per meeting, deprecation notice will go ahead. There's less certainty about how and when we're going to stop compiling code that would go through the `volatile`-qualified call path
As noted in #5215, we do have a way of failing compilation for the case where we'd select a method taking `volatile`-qualified parameters, but doing so basically requires maintaining support...