Hi Wei, Ye maintains the llvm modules, so he's the best for answering questions about that. But quick question: Is there a reason you want to use standard LLVM (which isn't part of the Aurora SDK) instead of the Aurora SDK ("module load oneapi") for SYCL coding? ("module load oneapi" will put Intel's LLVM which implements DPC++/SYCL in your path, and uses the "dpcpp" wrapper instead of "clang -fsycl ..." to invoke it.) Thanks, Colleen ________________________________ From: Ecp-aurora-sdk-discuss <[email protected]> on behalf of Jiang, Wei via Ecp-aurora-sdk-discuss <[email protected]> Sent: Thursday, June 2, 2022 2:06 PM To: Luo, Ye <[email protected]>; [email protected] <[email protected]>; Jiang, Wei <[email protected]> Subject: Re: [Ecp-aurora-sdk-discuss] clang compiler & LLVM module load To avoid the runtime conflicts, I just manually added clang13 binary path to PATH without explicitly loading llvm module, and then passed compilation without previous linking error. However, when I ran the code, I received error "No kernel named .....ffiPKfPKN2cl4sycl3vecIfLi4EEESY_iNSV_IfLi3EEESZ_SZ_PT_S11_PdRNSU_5queueEiiENKUlRNSU_7handlerEE_clES16_EUlNSU_7nd_itemILi3EEEE_ was found -46 (CL_INVALID_KERNEL_NAME)Exception caught at file ...". Similar error occurred to my previous sycl -> cuda code migration with codeplay oneapi (uses clang13). The current clang compiler seems involved with cuda rts. ________________________________ From: Ecp-aurora-sdk-discuss <[email protected]> on behalf of Jiang, Wei via Ecp-aurora-sdk-discuss <[email protected]> Sent: Thursday, June 2, 2022 1:43 PM To: Luo, Ye <[email protected]>; [email protected] <[email protected]> Subject: Re: [Ecp-aurora-sdk-discuss] clang compiler & LLVM module load I am asking what is the difference between the current and previous installation of clang/llvm on JLSE. Can anybody help answering? ________________________________ From: Luo, Ye <[email protected]> Sent: Thursday, June 2, 2022 1:28 PM To: Jiang, Wei <[email protected]>; [email protected] <[email protected]> Subject: Re: clang compiler & LLVM module load When I loaded llvm/release-13.0.1, I see "cuda/11.0.2 " is automatically loaded. But when I "module unload cuda/11.0.2", then module llvm/release-13.0.1 is also unloaded automatically. The cuda module is a dependency of the llvm module and unloading cuda unloads llvm The reason why I am concerned this is because, when I recompiled my sycl code, I got clang++ linking error "...ld: /soft/restricted/CNDA/sdk/2022.01.30.001/oneapi/mkl/20220311/mkl/lib/intel64/libmkl_sycl.so: undefined reference to `clCreateProgramWithIL". This is an error related to runtime system conflicts. For the same code, previously there was no linking error with clang++. ​The cuda module doesn't add any path at linking. To understand why the link failure, you will need to extract the exact linking command line and debug the issue.The mkl_sycl.so looks for an OpenCL runtime, the "undefined reference" error indicates an incompatible one is being used. You may add -v to clang++ to figure out which one is being picked up and why. This is why I am asking if any big change of clang compiler/llvm module on JLSE. There is no change in llvm modules. All the llvm modules at /soft/modulefiles/llvm loads a CUDA module. If you succeeded in the past, it must be a different clang/llvm installation. Ye ________________________________ From: Jiang, Wei <[email protected]> Sent: Thursday, June 2, 2022 12:34 PM To: Luo, Ye <[email protected]>; [email protected] <[email protected]> Subject: Re: clang compiler & LLVM module load When I loaded llvm/release-13.0.1, I see "cuda/11.0.2 " is automatically loaded. But when I "module unload cuda/11.0.2", then module llvm/release-13.0.1 is also unloaded automatically. The reason why I am concerned this is because, when I recompiled my sycl code, I got clang++ linking error "...ld: /soft/restricted/CNDA/sdk/2022.01.30.001/oneapi/mkl/20220311/mkl/lib/intel64/libmkl_sycl.so: undefined reference to `clCreateProgramWithIL". This is an error related to runtime system conflicts. For the same code, previously there was no linking error with clang++. This is why I am asking if any big change of clang compiler/llvm module on JLSE. ________________________________ From: Luo, Ye <[email protected]> Sent: Thursday, June 2, 2022 11:00 AM To: [email protected] <[email protected]>; Jiang, Wei <[email protected]> Subject: Re: clang compiler & LLVM module load Hi Wei, Hi, I notice on JLSE the clang compiler is put into llvm module recently, and loading llvm module requires cuda dependency and therefore essentially linking cudarts.lib. The red part is not true. Users remain responsible to control the linking. Does it mean the clang compiler is set as a compiler "default" for CUDA rts? Clang is compiler. cudarts.libs are just libraries. libraries have no idea about the compiler. So nothing as "default". In short, even if the llvm module loads cuda module, clang doesn't actively engage CUDA toolchain unless being explicitly requested for example when -fopenmp-targets=nvptx64 or compiling cu source code. Ye