Daniel Arndt

icon indicating a website link https://www.ornl.gov/staff-profile/daniel-arndt icon indicating an email [email protected]

icon company Oak Ridge National Lab icon location Oak Ridge icon location Large Scale Simulations Computational Scientist. One of the developers of the deal.II finite element library and Kokkos.

Results 776 comments of Daniel Arndt

parallel_scan with return_value does not check that ReturnType is correct

In particular, I get ``` [...] /tmp/kokkos/core/src/Serial/Kokkos_Serial_Parallel_Range.hpp:334:44: error: cannot convert ‘Kokkos::View::pointer_type {aka int*}’ to ‘const pointer_type {aka long long int* const}’ in initialization m_result_ptr(arg_result_view.data()) { ``` with the first example...

Try reenabling OpenMPTarget+ROCm CI

The compiler still crashes with output like ``` stack dump: 0. Program arguments: /opt/rocm-5.2.0/llvm/bin/llc /tmp/libkokkoscore-d984d8-gfx908-optimized-f7957c.bc -mtriple=amdgcn-amd-amdhsa -mcpu=gfx908 -filetype=obj --amdhsa-code-object-version=4 -amdgpu-spill-cfi-saved-regs -o /tmp/libkokkoscore-d984d8-gfx908-145983.o 1. Running pass 'CallGraph Pass Manager' on module...

`OpenMPTarget` requires 32 threads per team but no `Kokkos::TeamPolicy<...>::team_size_min()`

I think we consider `OpenMPTarget`'s requirement for a minimum team size a FIXME and that there is no need for such a function really.

Nightly build failures with intel/19, "missing return statement at end of non-void function"

Fixed in #5433.

Nightly build failures with intel/19, "missing return statement at end of non-void function"

Looks like some version of std::unreachable would also do the trick (at least for ICC), see [godbolt.org/z/99T84x4cb](https://godbolt.org/z/99T84x4cb).

Try enabling UBSan and ASan in one build

Retest this please.

Use Kokkos::Tools::Experimental::device_id for all Profiling events

No, there was no work done towards the progress of this issue.

Suppress warning: function declared with "noreturn" does return

@stanmoore1 Would you mind checking that #5441 fixes this for you?

Deadlock ThreadVectorRange for SYCL+CUDA in incremental Tests 12a and 12b

> @masterleinad is this still an issue? Yes, when I tested this recently, I was still seeing it.

Deadlock ThreadVectorRange for SYCL+CUDA in incremental Tests 12a and 12b

See https://github.com/kokkos/kokkos/pull/4676. We need intel/llvm#6169 or intel/llvm#4903 to fix this.