Skip to content

Conversation

bd1976bris
Copy link
Collaborator

@bd1976bris bd1976bris commented Jul 15, 2025

Not all builds name the compiler executable clang. For example, the Fuchsia build bots use llvm as their single toolchain executable name, as they combine everything together in a busybox-style binary.

Update the Clang driver test to simply check that a non-empty path is provided for the --thinlto-remote-compiler argument, rather than hardcoding the executable name. The cross-project test will verify that the path is valid later.

Should fix #147265.

Not all builds name the compiler executable `clang`. For example,
the Fuchsia build bots use `llvm` as the executable name, as they
combine everything together in a busybot-style binary.

Update the Clang driver test to simply check that a non-empty path
is provided for the `--thinlto-remote-compiler` argument, rather
than hardcoding the executable name. The cross-project test will
verify that the path is valid later.

Should fix llvm#147265.
@llvmbot llvmbot added clang Clang issues not falling into any other category clang:driver 'clang' and 'clang++' user-facing binaries. Not 'clang-cl' labels Jul 15, 2025
@bd1976bris bd1976bris requested a review from nga888 July 15, 2025 17:46
@llvmbot
Copy link
Member

llvmbot commented Jul 15, 2025

@llvm/pr-subscribers-clang-driver

@llvm/pr-subscribers-clang

Author: bd1976bris (bd1976bris)

Changes

Not all builds name the compiler executable clang. For example, the Fuchsia build bots use llvm as their single toolchain executable name, as they combine everything together in a busybot-style binary.

Update the Clang driver test to simply check that a non-empty path is provided for the --thinlto-remote-compiler argument, rather than hardcoding the executable name. The cross-project test will verify that the path is valid later.

Should fix #147265.


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

1 Files Affected:

  • (modified) clang/test/Driver/DTLTO/dtlto.c (+1-1)
diff --git a/clang/test/Driver/DTLTO/dtlto.c b/clang/test/Driver/DTLTO/dtlto.c
index d72e487e706b2..96795d9a4e6a4 100644
--- a/clang/test/Driver/DTLTO/dtlto.c
+++ b/clang/test/Driver/DTLTO/dtlto.c
@@ -10,7 +10,7 @@
 
 // FORWARD: ld.lld
 // FORWARD-SAME: "--thinlto-distributor=d.exe"
-// FORWARD-SAME: "--thinlto-remote-compiler={{.*}}clang{{[^\"]*}}"
+// FORWARD-SAME: "--thinlto-remote-compiler={{[^"]+}}"
 // FORWARD-SAME: "--thinlto-distributor-arg=a1"
 // FORWARD-SAME: "--thinlto-distributor-arg=a2"
 // FORWARD-SAME: "--thinlto-distributor-arg=a3"

@bd1976bris bd1976bris requested a review from ilovepi July 15, 2025 17:47
Copy link
Collaborator

@nga888 nga888 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@bd1976bris bd1976bris merged commit edfec9c into llvm:main Jul 15, 2025
11 of 12 checks passed
bd1976bris added a commit to bd1976bris/llvm-project that referenced this pull request Sep 16, 2025
…bots

Not all builds name the compiler executable clang. For example, the
Fuchsia buildbots use llvm as their single toolchain executable name, as
they combine everything together in a busybox-style binary. This is
currently causing the new ps5-dtlto.c to fail on such build bots.

Update the Clang driver tests to simply check that a non-empty path is
provided for the --thinlto-remote-compiler argument, rather than
hardcoding the executable name. The cross-project tests will verify that
the path is valid later.

This is the same fix as applied earlier in llvm#148908. However, that fix
left a case in the dtlto.c test that was subsequently reflected into the
new ps5-dtlto.c test where it caused a failure. Why it doesn't cause a
failure in the existing dtlto.c test is a mystery to me - perhaps the
substring "clang" is now included in the path to the busybox-style binary,
or perhaps that test was disabled for affected buildbots and then not
re-enabled? It's clearly a latent issue though so I have also fixed the
dtlto.c test in this patch.

Should fix the buildbot failures caused by: llvm#158041.
bd1976bris added a commit to bd1976bris/llvm-project that referenced this pull request Sep 16, 2025
Previously I masked issues with Multicall + DTLTO (see llvm#148908) due to an
incomplete understanding of how the Multicall toolchain works.

This patch reverts those incorrect changes and instead marks the
affected tests XFAIL when running under Multicall.

Issue llvm#159125 tracks fixing DTLTO with Multicall.
bd1976bris added a commit that referenced this pull request Sep 16, 2025
)

Previously I masked issues with Multicall + DTLTO (see #148908) due to
an incomplete understanding of how the Multicall toolchain works.

This patch reverts those incorrect changes and instead marks the
affected tests XFAIL when running under Multicall.

Issue #159125 tracks fixing DTLTO with Multicall.
bd1976bris added a commit that referenced this pull request Sep 16, 2025
)

Make the test regexes more permissive to fix buildbot failures caused by
the merge of PR #159129. This mirrors the earlier fix in PR #148908. We
retain cross-project-test coverage to verify that the path content is
correct.

A follow-up will update the tests to robustly check the Clang executable
filename, likely along the lines of PR #159151.

Short-term unbreak to keep the buildbots green without reverting a chain
of commits.
kimsh02 pushed a commit to kimsh02/llvm-project that referenced this pull request Sep 19, 2025
…#159129)

Previously I masked issues with Multicall + DTLTO (see llvm#148908) due to
an incomplete understanding of how the Multicall toolchain works.

This patch reverts those incorrect changes and instead marks the
affected tests XFAIL when running under Multicall.

Issue llvm#159125 tracks fixing DTLTO with Multicall.
kimsh02 pushed a commit to kimsh02/llvm-project that referenced this pull request Sep 19, 2025
…#159158)

Make the test regexes more permissive to fix buildbot failures caused by
the merge of PR llvm#159129. This mirrors the earlier fix in PR llvm#148908. We
retain cross-project-test coverage to verify that the path content is
correct.

A follow-up will update the tests to robustly check the Clang executable
filename, likely along the lines of PR llvm#159151.

Short-term unbreak to keep the buildbots green without reverting a chain
of commits.
itzexpoexpo pushed a commit to itzexpoexpo/llvm-project that referenced this pull request Sep 21, 2025
…#159129)

Previously I masked issues with Multicall + DTLTO (see llvm#148908) due to
an incomplete understanding of how the Multicall toolchain works.

This patch reverts those incorrect changes and instead marks the
affected tests XFAIL when running under Multicall.

Issue llvm#159125 tracks fixing DTLTO with Multicall.
itzexpoexpo pushed a commit to itzexpoexpo/llvm-project that referenced this pull request Sep 21, 2025
…#159158)

Make the test regexes more permissive to fix buildbot failures caused by
the merge of PR llvm#159129. This mirrors the earlier fix in PR llvm#148908. We
retain cross-project-test coverage to verify that the path content is
correct.

A follow-up will update the tests to robustly check the Clang executable
filename, likely along the lines of PR llvm#159151.

Short-term unbreak to keep the buildbots green without reverting a chain
of commits.
SeongjaeP pushed a commit to SeongjaeP/llvm-project that referenced this pull request Sep 23, 2025
…#159129)

Previously I masked issues with Multicall + DTLTO (see llvm#148908) due to
an incomplete understanding of how the Multicall toolchain works.

This patch reverts those incorrect changes and instead marks the
affected tests XFAIL when running under Multicall.

Issue llvm#159125 tracks fixing DTLTO with Multicall.
SeongjaeP pushed a commit to SeongjaeP/llvm-project that referenced this pull request Sep 23, 2025
…#159158)

Make the test regexes more permissive to fix buildbot failures caused by
the merge of PR llvm#159129. This mirrors the earlier fix in PR llvm#148908. We
retain cross-project-test coverage to verify that the path content is
correct.

A follow-up will update the tests to robustly check the Clang executable
filename, likely along the lines of PR llvm#159151.

Short-term unbreak to keep the buildbots green without reverting a chain
of commits.
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