correcting email address. On Jun 24, 2022, at 6:07 PM, Asim YarKhan <[email protected]<mailto:[email protected]>> wrote: The ECP SLATE project is having a problem on the JLSE arcticus hardware that may be the same as reported in the "JLSE Aurora SDK Bug, Issue and Request Tracker" as issue number CMPLRLLVM-37963 This is also the same bug reported publicly in the Intel oneAPI Base Toolkit issue tracker at https://community.intel.com/t5/Intel-oneAPI-Base-Toolkit/sycl-queue-memcpy-s... The problem is that SLATE uses sycl::queue::memcpy() to move data between users (c-malloc'ed) memory and device (sycl::malloc_shared) memory. For larger data sizes and for sizes that vary (i.e. double precision matrices of 8000,9000) the memcpy() can han The Intel memcpy documentation says that for a sycl::queue::memcpy() the src and dest must both be USM allocations https://intel.github.io/llvm-docs/doxygen/classcl_1_1sycl_1_1queue.html#a6bc... However, the SYCL standard states explicitly that both dest and src may be either host or USM pointers. https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#su... I have a reproducer based on the oneAPI-samples/Libraries/oneMKL/matrix_mul_mkl/ sample, but I believe that this problem is just a replica of the "JLSE Aurora SDK Bug, Issue and Request Tracker" issue number CMPLRLLVM-37963, so I have not submitted it separately. Please inform me if you need/prefer an additional reproducer for this sycl::queue::memcpy () behavior. It would be very important for SLATE to be able to move data from user c-allocation to device allocations. Regards, Asim YarKhan Innovative Computing Lab, University of Tennessee