Luc Berger
Luc Berger
@dalg24 good point, I reproduced on both my laptop (apple arm clang 13.1), my workstation (gcc 10) and the original failure is in our CI (apple clang 13.0) so this...
Yeah, I was a bit surprised that our code was able to call the constructor wrongly like that, it has been doing so for a while. I can leave this...
Should we rename the `CUDA` line to `nvcc`? Also just for information, llvm is also requiring c++17 to build its projects and proposes the following [minimum requirements](https://discourse.llvm.org/t/rfc-increasing-the-gcc-and-clang-requirements-to-support-c-17-in-llvm/59983)
@ndellingwood @e10harvey Adding you here so that when the final decision is made we can update the compilers we use in Kokkos Kernels testing accordingly
Thanks @ndellingwood, I should probably close this issue unless you want to keep it to track things in 3.6.0?
@srajama1 that's actually not completely true. If this branch is rebased on top of #1381 then it will cleanly rebase on top of develop after the other PR merges. Of...
That makes sense and a rebase on top of develop will provide a clean branch that can easily be picked for cherry-pick in Trilinos. I am not sure that merging...
@dialecticDolt we are compiling with -Werror so if you have unused parameters in some code branch that will create issues in the auto-tester.
Thanks for the change, let us retest this PR and see what comes out!
Thanks for pointing this out to us, we will look at how we want to handle these return values.