libclc spirv-mesa3d/spirv64-mesa3d targets fail to build on LLVM 23.1: "SPIR-V target requires a Vulkan environment"
- Dominant language
- LLVM
- Stars
- 40.5k
- Forks
- 18.7k
- PR merge metrics
- PR metrics pending
Description
Building the spirv-mesa3d- / spirv64-mesa3d- libclc runtime targets (used by Mesa's intel_clc/mesa_clc) fails on LLVM 23.1 because Clang now rejects the spirv-unknown-mesa3d triple used internally by libclc for these targets. This worked on LLVM 22.x.
**Environment**
LLVM/Clang: 23.1.0 (in-tree build)
Component: libclc (runtimes build)
Target triple: spirv-mesa3d- / spirv64-mesa3d-
OS: Linux
**Steps to reproduce**
```
cmake ../llvm -G Ninja \
-DCMAKE_BUILD_TYPE=Release \
-DLLVM_ENABLE_PROJECTS="clang" \
-DLLVM_RUNTIME_TARGETS="spirv-mesa3d-;spirv64-mesa3d-" \
-DRUNTIMES_spirv-mesa3d-_LLVM_ENABLE_RUNTIMES=libclc \
-DRUNTIMES_spirv64-mesa3d-_LLVM_ENABLE_RUNTIMES=libclc
ninja
```
Observed error
```
/path/to/clang -x cl -DCLC_SPIRV ... --target=spirv-unknown-mesa3d -nostdlib \
-nostdlibinc -cl-no-stdinc -cl-std=CL3.0 -c -o clc_atomic_fetch_and.cl.o \
clc_atomic_fetch_and.cl
error: SPIR-V target requires a Vulkan environment
```
The same failure occurs for every .cl file in the target, both spirv-mesa3d- and spirv64-mesa3d-. LIBCLC_USE_SPIRV_BACKEND does not help — it only affects the final bitcode-to-.spv translation step, not this front-end .cl -> .bc compile.
**Expected behavior**
Same as LLVM ≤22.x: Clang treats the SPIR-V arch with an unrecognized/legacy OS component (mesa3d) as an OpenCL-style target (physical addressing) and compiles successfully, producing .bc files later converted via llvm-spirv/the in-tree backend into spirv-mesa3d-.spv / spirv64-mesa3d-.spv, which Mesa's intel_clc depends on.
**Suspected root cause**
This looks related to the SPIR-V backend being promoted from experimental to official status in this release cycle (#123654) and related triple-handling hardening for SPIR-V targets (e.g. #89796, #70051). The target-info allocation logic in clang/lib/Basic/Targets.cpp for llvm::Triple::spirv/spirv64 appears to now require a recognized Vulkan environment whenever the OS field is not literally unknown, whereas libclc's mesa3d targets have always used a non-standard OS string (mesa3d) on the assumption it would fall back to OpenCL/physical-addressing semantics.
libclc's spirv-mesa3d-/spirv64-mesa3d- targets (CMakeLists.txt / cmake/modules/AddLibclc.cmake) have not been updated to match this stricter validation.
**Impact**
Breaks the standard way Mesa (intel_clc, mesa_clc) obtains libclc.pc and the Mesa SPIR-V bitcode when building against LLVM 23.1, since this is now the only supported way to build libclc's SPIR-V-for-Mesa targets on trunk.
**Suggested fix directions**
Either relax the Clang target-info check to still allow the legacy mesa3d (and other historically-tolerated non-Vulkan) OS strings for spirv/spirv64, or
Update libclc's mesa3d target definitions to use a triple form that Clang 23 accepts while still producing OpenCL-compatible SPIR-V (e.g. an explicit OpenCL environment component instead of relying on OS-field fallback).
**Additional context**
Related:
#135327 (switch libclc off external llvm-spirv),
#151347 (LIBCLC_USE_SPIRV_BACKEND option) — neither addresses this front-end compile failure.
Contributor guide
Research direction
Reproduce the failure with the provided CMake and Ninja commands for the spirv-mesa3d- and spirv64-mesa3d- runtimes. Read clang/lib/Basic/Targets.cpp and libclc's CMakeLists.txt and cmake/modules/AddLibclc.cmake to compare target handling with LLVM 22.x. Done means both targets build successfully and compile their .cl sources into the expected bitcode outputs.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cmake
- Domain
- build-system, compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100