-
Notifications
You must be signed in to change notification settings - Fork 407
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
Tell Trilinos packages about host+device lambda #1019
Comments
We have a naming & definition inconsistency with our LAMBDA macros that needs to be fixed. |
The meaning of the |
Also added a compile-time check to make sure this behaves as expected. [#1019]
Nope, it doesn't change the behavior of
|
@ibaned Just to clarify: Before, with CUDA 7.5, |
Specific is good :) Edit: I haven't actually tested this with a real configuration |
So PR #1020 tried to fix this but introduced a warning in Trilinos builds:
I guess this flag used to have meaning as input, back when C++11 was optional. This warning blocks promotion, even though its not a compile error or runtime issue, we'll look very bad if we let it get into Trilinos (also it makes the meaning of the output flag wrong). Will open a PR momentarily to remove any input meaning of |
Please see the discussion in trilinos/Trilinos#1278 about how to manage the move away from CUDA 7.5 with
#ifdef
s.This issue in particular is my proposal that Kokkos define some preprocessor symbol in the cases where a
KOKKOS_LAMBDA
will work in all enabled execution spaces, as determined by the existing logic inKokkos_Macros.hpp
. Downstream Trilinos packages can then#ifdef
their code based on this symbol, and handle the negative case with functors during the remaining period of support for CUDA 7.5, while being able to move forward with new CUDA 8.0-style lambda-based development.The text was updated successfully, but these errors were encountered: