Skip to content

Conversation

@jhuber6
Copy link
Contributor

@jhuber6 jhuber6 commented Oct 21, 2025

Summary:
The new driver uses an embedded clang job to handle the device
compilation. This correctly returns the linker as being ld.lld. The
CMake parser to detect things like OpenMP support in the linker will
parse the output of -v for the linker job. If the user is also using
LLD for their linker, it will think this job is the linker and then fail
as it does not see the required libraries. For these special HIP
compilations, just print the linker wrapper invocation and nothing else.
This will still show users the steps used to generate the binary but it
will hack around this issue.

Summary:
The new driver uses an embedded clang job to handle the device
compilation. This correctly returns the linker as being `ld.lld`. The
CMake parser to detect things like OpenMP support in the linker will
parse the output of `-v` for the linker job. If the user is also using
LLD for their linker, it will think this job is the linker and then fail
as it does not see the required libraries. For these special HIP
copmilations, just print the linker wrapper invocation and nothing else.
This will still show users the steps used to generate the binary but it
will hack around this issue.
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' labels Oct 21, 2025
@llvmbot
Copy link
Member

llvmbot commented Oct 21, 2025

@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: Joseph Huber (jhuber6)

Changes

Summary:
The new driver uses an embedded clang job to handle the device
compilation. This correctly returns the linker as being ld.lld. The
CMake parser to detect things like OpenMP support in the linker will
parse the output of -v for the linker job. If the user is also using
LLD for their linker, it will think this job is the linker and then fail
as it does not see the required libraries. For these special HIP
copmilations, just print the linker wrapper invocation and nothing else.
This will still show users the steps used to generate the binary but it
will hack around this issue.


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

2 Files Affected:

  • (modified) clang/lib/Driver/ToolChains/Clang.cpp (+9-1)
  • (modified) clang/test/Driver/hip-toolchain-no-rdc.hip (+7)
diff --git a/clang/lib/Driver/ToolChains/Clang.cpp b/clang/lib/Driver/ToolChains/Clang.cpp
index a7310ba2da061..caf74786aebea 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -9099,6 +9099,9 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
   };
   auto ShouldForward = [&](const llvm::DenseSet<unsigned> &Set, Arg *A,
                            const ToolChain &TC) {
+    // CMake hack to avoid printing verbose informatoin for HIP non-RDC mode.
+    if (A->getOption().matches(OPT_v) && JA.getType() == types::TY_Object)
+      return false;
     return (Set.contains(A->getOption().getID()) ||
             (A->getOption().getGroup().isValid() &&
              Set.contains(A->getOption().getGroup().getID()))) &&
@@ -9174,7 +9177,12 @@ void LinkerWrapper::ConstructJob(Compilation &C, const JobAction &JA,
 
   CmdArgs.push_back(
       Args.MakeArgString("--host-triple=" + getToolChain().getTripleString()));
-  if (Args.hasArg(options::OPT_v))
+
+  // CMake hack, suppress passing verbose arguments for the special-case HIP
+  // non-RDC mode compilation. This confuses default CMake implicit linker
+  // argument parsing when the language is set to HIP and the system linker is
+  // also `ld.lld`.
+  if (Args.hasArg(options::OPT_v) && JA.getType() != types::TY_Object)
     CmdArgs.push_back("--wrapper-verbose");
   if (Arg *A = Args.getLastArg(options::OPT_cuda_path_EQ))
     CmdArgs.push_back(
diff --git a/clang/test/Driver/hip-toolchain-no-rdc.hip b/clang/test/Driver/hip-toolchain-no-rdc.hip
index 2f40fd478671e..840334e19e7f2 100644
--- a/clang/test/Driver/hip-toolchain-no-rdc.hip
+++ b/clang/test/Driver/hip-toolchain-no-rdc.hip
@@ -214,3 +214,10 @@
 // AMDGCNSPIRV: {{".*clang-offload-bundler.*"}} "-type=o"
 // AMDGCNSPIRV-SAME: "-targets={{.*}}hipv4-spirv64-amd-amdhsa--amdgcnspirv,hipv4-amdgcn-amd-amdhsa--gfx900"
 // AMDGCNSPIRV-SAME: "-input=[[AMDGCNSPV_CO]]" "-input=[[GFX900_CO]]"
+
+// Check verbose printing with the new driver.
+// RUN: %clang -### --target=x86_64-linux-gnu -fno-gpu-rdc -nogpulib -nogpuinc \
+// RUN:   --offload-new-driver --offload-arch=gfx908 -v %s 2>&1 | FileCheck %s --check-prefix=VERBOSE
+// VERBOSE: clang-linker-wrapper
+// VERBOSE-NOT: --device-compiler=amdgcn-amd-amdhsa=-v
+// VERBOSE-NOT: --wrapper-verbose

@arsenm arsenm changed the title [HIP] Hack around CMake incorrectly parsing OpenPM support in HIP mode [HIP] Hack around CMake incorrectly parsing OpenMP support in HIP mode Oct 22, 2025
@jhuber6 jhuber6 merged commit 65850de into llvm:main Oct 22, 2025
13 checks passed
dvbuka pushed a commit to dvbuka/llvm-project that referenced this pull request Oct 27, 2025
llvm#164482)

Summary:
The new driver uses an embedded clang job to handle the device
compilation. This correctly returns the linker as being `ld.lld`. The
CMake parser to detect things like OpenMP support in the linker will
parse the output of `-v` for the linker job. If the user is also using
LLD for their linker, it will think this job is the linker and then fail
as it does not see the required libraries. For these special HIP
compilations, just print the linker wrapper invocation and nothing else.
This will still show users the steps used to generate the binary but it
will hack around this issue.
Lukacma pushed a commit to Lukacma/llvm-project that referenced this pull request Oct 29, 2025
llvm#164482)

Summary:
The new driver uses an embedded clang job to handle the device
compilation. This correctly returns the linker as being `ld.lld`. The
CMake parser to detect things like OpenMP support in the linker will
parse the output of `-v` for the linker job. If the user is also using
LLD for their linker, it will think this job is the linker and then fail
as it does not see the required libraries. For these special HIP
compilations, just print the linker wrapper invocation and nothing else.
This will still show users the steps used to generate the binary but it
will hack around this issue.
aokblast pushed a commit to aokblast/llvm-project that referenced this pull request Oct 30, 2025
llvm#164482)

Summary:
The new driver uses an embedded clang job to handle the device
compilation. This correctly returns the linker as being `ld.lld`. The
CMake parser to detect things like OpenMP support in the linker will
parse the output of `-v` for the linker job. If the user is also using
LLD for their linker, it will think this job is the linker and then fail
as it does not see the required libraries. For these special HIP
compilations, just print the linker wrapper invocation and nothing else.
This will still show users the steps used to generate the binary but it
will hack around this issue.
lamb-j pushed a commit to ROCm/llvm-project that referenced this pull request Nov 3, 2025
llvm#164482)

Summary:
The new driver uses an embedded clang job to handle the device
compilation. This correctly returns the linker as being `ld.lld`. The
CMake parser to detect things like OpenMP support in the linker will
parse the output of `-v` for the linker job. If the user is also using
LLD for their linker, it will think this job is the linker and then fail
as it does not see the required libraries. For these special HIP
compilations, just print the linker wrapper invocation and nothing else.
This will still show users the steps used to generate the binary but it
will hack around this issue.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' clang Clang issues not falling into any other category

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants