Compiler crashes when linking dynamically SYCL kernels and functions called inside it

[fbarbari]

Describe the bug

Linking fails when trying to link a file which contains a SYCL kernel calling a function contained inside a different library. This happens only with dynamic linking. With static linking, it works.

Basically, if a SYCL kernel calls a function declared and compiled elsewhere, during the dynamic linking phase, the compiler crashes with this error:

...
warning: Undefined function _Z3sumdd found in /scratch_local/icpx-dee970ba03/main-8d7ef7.bc. This may result in runtime errors.

build log:
Compilation started
Compilation done
Linking started
Linking done
Device build started
Options used by backend compiler:  -I "/scratch_local/icpx-dee970ba03"
Failed to build device program
remark: <unknown>:0:0: loop not vectorized: Cannot vectorize uncountable loop
remark: <unknown>:0:0: Kernel was 16-way vectorized
remark: <unknown>:0:0: Kernel was 16-way vectorized
remark: <unknown>:0:0: Kernel was 16-way vectorized
remark: <unknown>:0:0: 69 instructions in function
remark: <unknown>:0:0: 35 instructions in function
remark: <unknown>:0:0: 235 instructions in function
CompilerException Failed to lookup symbol _ZTSN4sycl3_V16detail18RoundedRangeKernelINS0_4itemILi1ELb1EEELi1EZNS0_7handler4fillIdEEvPvRKT_mEUlNS0_2idILi1EEEE_EE
JIT session error: Symbols not found: [ _Z3sumdd ]
Failed to materialize symbols: { (main, { _ZTSZN4sycl3_V17handler4fillIdEEvPvRKT_mEUlNS0_2idILi1EEEE_, _ZTSN4sycl3_V16detail18RoundedRangeKernelINS0_4itemILi1ELb1EEELi1EZNS0_7handler4fillIdEEvPvRKT_mEUlNS0_2idILi1EEEE_EE, _ZTSZZ4mainENKUlRN4sycl3_V17handlerEE_clES2_EUlNS0_7nd_itemILi1EEEE_ }) }


Failed to build: : -11 (CL_BUILD_PROGRAM_FAILURE)

llvm-foreach: 
icpx: error: x86_64 compiler command failed with exit code 245 (use -v to see invocation)
...

To reproduce

I have prepared a small reproducible example here along with instructions to compile and run.

Environment

• OS: RHEL 8.8

Reproduced the bug with oneAPI 2026.0.0, 2025.2.0 and 2025.1.1.

Additional context

The bug appears both when targeting spir64_x86_64 and nvptx64-nvidia-cuda, but not when targeting spir64 on the CPU.

[dyniols]

I will take a look.

[dyniols]

@fbarbari
Thanks for the report. After checking looks like it's known limitation and OpenCL CPU backend doesn't support it yet.
What's missing is specifically the OpenCL CPU backend ability to link AOT native device binaries produced by opencl-aot. Until that backend gains that capability the only working OpenCL CPU paths are static linking or using JIT (spir64).

Since it's not a bug we can move it from bug to enhancement category?

[fbarbari]

Thank you @dyniols for the quick response.

Does this also apply to the CUDA backend?

Since it's not a bug we can move it from bug to enhancement category?

I don't know if this was intended for me, but in that case i'd say it's fine.

[dyniols]

Does this also apply to the CUDA backend?

I believe so.

I don't know if this was intended for me, but in that case i'd say it's fine.

Okay

[dyniols]

Moved to enhancement label because currently SYCL doesn't support AOT compilation with linking dynamically SYCL kernels in CUDA and OpenCL CPU backends.