SYCL runtime crashes during teardown when static cache is used for kernels built with SYCL compiler API
- Dominant language
- LLVM
- Stars
- 1.5k
- Forks
- 854
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 137
Description
### Describe the bug
As part of FFT kernel integration to torch-xpu-ops https://github.com/intel/torch-xpu-ops/pull/3962 we discovered that kernel_bundles built by create_kernel_bundle_from_source() and stored in static cache cause crashes during process exit with segmentation faults or "pure virtual function called" errors.
The crash occurs because kernel bundle destructors attempt to access SYCL runtime context/adapter objects that have already been destroyed during static teardown.
I can reproduce the problem with one of the latest daily builds:
```
DPC++ compiler 7.1.0 (pre-release) (Nightly 2026-07-26) build based on:
clang version 23.0.0git (https://github.com/intel/llvm d169ba4e202112988439e56372560bacfdb9824b)
```
### To reproduce
1. reproducer: [repro_fft.txt](https://github.com/user-attachments/files/30470092/repro_fft.txt)
2. `mv repro_fft.txt repro_fft.cpp ; dpclang++ -fsycl repro_fft.cpp`
3. `./a.out`
4. Segfault at the end of execution, expected successful teardown
### Environment
- OS: Linux
- Target device and vendor: Intel GPU, and CPU
- DPC++ version: DPC++ compiler 7.1.0 (pre-release) (Nightly 2026-07-26) build based on: clang version 23.0.0git (https://github.com/intel/llvm d169ba4e202112988439e56372560bacfdb9824b)
### Additional context
As a workaround we used dynamic allocation for the cache and let it leak, you can enable the workaround by defining `-DLEAK_SINGLETON` macro:
`dpclang++ -fsycl -DLEAK_SINGLETON repro_fft.cpp`
The problem is going to be fixed in https://github.com/intel/llvm/pull/22785
CC: @dvrogozh
Contributor guide
Research direction
Start by renaming repro_fft.txt to repro_fft.cpp, then build and run it with dpclang++ -fsycl to reproduce the teardown crash. Compare the normal run with the -DLEAK_SINGLETON workaround and review PR 22785, which the issue identifies as the planned fix. Done means the reproducer exits successfully without a segmentation fault or pure virtual function error.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Clearly specified
- Newbie friendliness
- 25/100