https://github.com/bd1976bris created
https://github.com/llvm/llvm-project/pull/159050
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 #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: #158041.
>From de3ca157d8e63110376f30289bb65585cd5907d2 Mon Sep 17 00:00:00 2001
From: Dunbobbin <ben.dunbob...@sony.com>
Date: Tue, 16 Sep 2025 12:20:42 +0100
Subject: [PATCH] [DTLTO][TEST] Fix the DTLTO Clang driver tests failing on
some build 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 #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: #158041.
---
clang/test/Driver/DTLTO/dtlto.c | 2 +-
clang/test/Driver/DTLTO/ps5-dtlto.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/clang/test/Driver/DTLTO/dtlto.c b/clang/test/Driver/DTLTO/dtlto.c
index 96795d9a4e6a4..bb1bd4ace0487 100644
--- a/clang/test/Driver/DTLTO/dtlto.c
+++ b/clang/test/Driver/DTLTO/dtlto.c
@@ -35,7 +35,7 @@
// DEFAULT: ld.lld
// DEFAULT-SAME: "--thinlto-distributor=d.exe"
-// DEFAULT-SAME: "--thinlto-remote-compiler={{.*}}clang{{[^\"]*}}"
+// DEFAULT-SAME: "--thinlto-remote-compiler={{[^"]+}}"
/// Check that nothing is forwarded when the compiler is not in LTO mode, and
that
/// appropriate unused option warnings are issued.
diff --git a/clang/test/Driver/DTLTO/ps5-dtlto.c
b/clang/test/Driver/DTLTO/ps5-dtlto.c
index 9b70c88257a85..a37073b85aa32 100644
--- a/clang/test/Driver/DTLTO/ps5-dtlto.c
+++ b/clang/test/Driver/DTLTO/ps5-dtlto.c
@@ -35,7 +35,7 @@
// DEFAULT: prospero-lld
// DEFAULT-SAME: "--thinlto-distributor=d.exe"
-// DEFAULT-SAME: "--thinlto-remote-compiler={{.*}}clang{{[^\"]*}}"
+// DEFAULT-SAME: "--thinlto-remote-compiler={{[^"]+}}"
/// Check that the arguments are forwarded unconditionally even when the
/// compiler is not in LTO mode.
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
