Skip to content

[clang-linker-wrapper][lit] Fix OpenMP SPIR-V ELF test again #126142

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 7, 2025

Conversation

sarnex
Copy link
Member

@sarnex sarnex commented Feb 6, 2025

I was able to reproduce the issue with the sanitizer buildbot scripts and confirmed this fixes it.

The issue was the quotes, "0" is true in Python so we incorrectly added the spirv-tools feature even when the CMake variable was false. I don't know why it didn't always fail.

Also add the var to clang's BUILD.gn which matches what we do for other similar variables, however I don't think it has any effect on CI here.

@sarnex sarnex marked this pull request as ready for review February 7, 2025 17:43
@llvmbot llvmbot added the clang Clang issues not falling into any other category label Feb 7, 2025
@llvmbot
Copy link
Member

llvmbot commented Feb 7, 2025

@llvm/pr-subscribers-clang

Author: Nick Sarnie (sarnex)

Changes

I was able to reproduce the issue with the sanitizer buildbot scripts and confirmed this fixes it.

The issue was the quotes, "0" is true in Python so we incorrectly added the spirv-tools feature even when the CMake variable was false. I don't know why it didn't always fail.

Also add the var to clang's BUILD.gn which matches what we do for other similar variables, however I don't think it has any effect on CI here.


Full diff: https://github.com/llvm/llvm-project/pull/126142.diff

3 Files Affected:

  • (modified) clang/test/Tooling/clang-linker-wrapper-spirv-elf.cpp (-2)
  • (modified) clang/test/lit.site.cfg.py.in (+1-1)
  • (modified) llvm/utils/gn/secondary/clang/test/BUILD.gn (+1)
diff --git a/clang/test/Tooling/clang-linker-wrapper-spirv-elf.cpp b/clang/test/Tooling/clang-linker-wrapper-spirv-elf.cpp
index 50457f47868a028..4f8658064e857d0 100644
--- a/clang/test/Tooling/clang-linker-wrapper-spirv-elf.cpp
+++ b/clang/test/Tooling/clang-linker-wrapper-spirv-elf.cpp
@@ -1,6 +1,4 @@
 // Verify the ELF packaging of OpenMP SPIR-V device images.
-// FIXME: Re-enable when spirv-tools feature detection fixed
-// UNSUPPORTED: system-linux
 // REQUIRES: system-linux
 // REQUIRES: spirv-tools
 // RUN: mkdir -p %t_tmp
diff --git a/clang/test/lit.site.cfg.py.in b/clang/test/lit.site.cfg.py.in
index ce10e9128a1dfe1..6890da5327cb975 100644
--- a/clang/test/lit.site.cfg.py.in
+++ b/clang/test/lit.site.cfg.py.in
@@ -43,7 +43,7 @@ config.llvm_external_lit = path(r"@LLVM_EXTERNAL_LIT@")
 config.standalone_build = @CLANG_BUILT_STANDALONE@
 config.ppc_linux_default_ieeelongdouble = @PPC_LINUX_DEFAULT_IEEELONGDOUBLE@
 config.have_llvm_driver = @LLVM_TOOL_LLVM_DRIVER_BUILD@
-config.spirv_tools_tests = "@LLVM_INCLUDE_SPIRV_TOOLS_TESTS@"
+config.spirv_tools_tests = @LLVM_INCLUDE_SPIRV_TOOLS_TESTS@
 config.substitutions.append(("%llvm-version-major", "@LLVM_VERSION_MAJOR@"))
 
 import lit.llvm
diff --git a/llvm/utils/gn/secondary/clang/test/BUILD.gn b/llvm/utils/gn/secondary/clang/test/BUILD.gn
index 1c88d447658ce0c..2d6ad23ae58ce96 100644
--- a/llvm/utils/gn/secondary/clang/test/BUILD.gn
+++ b/llvm/utils/gn/secondary/clang/test/BUILD.gn
@@ -74,6 +74,7 @@ write_lit_config("lit_site_cfg") {
     "Python3_EXECUTABLE=$python_path",
     "USE_Z3_SOLVER=",
     "PPC_LINUX_DEFAULT_IEEELONGDOUBLE=0",
+    "LLVM_INCLUDE_SPIRV_TOOLS_TESTS=0",
   ]
 
   if (clang_enable_static_analyzer) {

@sarnex sarnex merged commit bfba621 into llvm:main Feb 7, 2025
11 checks passed
Icohedron pushed a commit to Icohedron/llvm-project that referenced this pull request Feb 11, 2025
…6142)

I was able to reproduce the issue with the sanitizer buildbot scripts
and confirmed this fixes it.

The issue was the quotes, `"0"` is true in Python so we incorrectly
added the `spirv-tools` feature even when the CMake variable was false.
I don't know why it didn't always fail.

Also add the var to clang's `BUILD.gn` which matches what we do for
other similar variables, however I don't think it has any effect on CI
here.

Signed-off-by: Sarnie, Nick <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
clang Clang issues not falling into any other category
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants