llvm / llvm/llvm-project

libclc spirv-mesa3d/spirv64-mesa3d targets fail to build on LLVM 23.1: "SPIR-V target requires a Vulkan environment"

Open
#218,800 5 comments 0 reactions 0 assignees View on GitHub
libclc question
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.