-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[offload] Unset -march
when building GPU libraries
#136442
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
Conversation
Unset `-march` when invoking the compiler and linker to build the GPU libraries. These libraries use GPU targets rather than the CPU targets, and an incidental `-march=native` causes Clang to be able to determine the GPU used — which causes the build to fail when there is no GPU available. Resetting `-march=` should suffice to revert to building generic code for the time being. See the discussion in: llvm#126143 (comment)
@llvm/pr-subscribers-offload Author: Michał Górny (mgorny) ChangesUnset See the discussion in: Full diff: https://github.com/llvm/llvm-project/pull/136442.diff 1 Files Affected:
diff --git a/offload/DeviceRTL/CMakeLists.txt b/offload/DeviceRTL/CMakeLists.txt
index 2da2ade94f4e4..346b65c887bba 100644
--- a/offload/DeviceRTL/CMakeLists.txt
+++ b/offload/DeviceRTL/CMakeLists.txt
@@ -137,9 +137,9 @@ function(compileDeviceRTLLibrary target_name target_triple)
BUILD_RPATH ""
INSTALL_RPATH ""
RUNTIME_OUTPUT_NAME libomptarget-${target_name}.bc)
- target_compile_options(libomptarget-${target_name} PRIVATE "--target=${target_triple}")
+ target_compile_options(libomptarget-${target_name} PRIVATE "--target=${target_triple}" "-march=")
target_link_options(libomptarget-${target_name} PRIVATE "--target=${target_triple}"
- "-r" "-nostdlib" "-flto" "-Wl,--lto-emit-llvm")
+ "-r" "-nostdlib" "-flto" "-Wl,--lto-emit-llvm" "-march=")
install(TARGETS libomptarget-${target_name}
PERMISSIONS OWNER_WRITE OWNER_READ GROUP_READ WORLD_READ
DESTINATION ${OFFLOAD_INSTALL_LIBDIR})
|
target_link_options(libomptarget-${target_name} PRIVATE "--target=${target_triple}" | ||
"-r" "-nostdlib" "-flto" "-Wl,--lto-emit-llvm") | ||
"-r" "-nostdlib" "-flto" "-Wl,--lto-emit-llvm" "-march=") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I vaguely remember we used to have an empty march before but it must have been removed at one point.
Thanks! |
Unset `-march` when invoking the compiler and linker to build the GPU libraries. These libraries use GPU targets rather than the CPU targets, and an incidental `-march=native` causes Clang to be able to determine the GPU used — which causes the build to fail when there is no GPU available. Resetting `-march=` should suffice to revert to building generic code for the time being. See the discussion in: llvm#126143 (comment)
Unset `-march` when invoking the compiler and linker to build the GPU libraries. These libraries use GPU targets rather than the CPU targets, and an incidental `-march=native` causes Clang to be able to determine the GPU used — which causes the build to fail when there is no GPU available. Resetting `-march=` should suffice to revert to building generic code for the time being. See the discussion in: llvm#126143 (comment)
Unset `-march` when invoking the compiler and linker to build the GPU libraries. These libraries use GPU targets rather than the CPU targets, and an incidental `-march=native` causes Clang to be able to determine the GPU used — which causes the build to fail when there is no GPU available. Resetting `-march=` should suffice to revert to building generic code for the time being. See the discussion in: llvm#126143 (comment)
Unset
-march
when invoking the compiler and linker to build the GPU libraries. These libraries use GPU targets rather than the CPU targets, and an incidental-march=native
causes Clang to be able to determine the GPU used — which causes the build to fail when there is no GPU available. Resetting-march=
should suffice to revert to building generic code for the time being.See the discussion in:
#126143 (comment)