On 5/31/23 10:57, Jeff Law wrote:
On 5/31/23 10:25, Vineet Gupta wrote:
Multilib testing on trunk is currently busted (and surprisingly this
affects any/all targets but it seems nobody cares). We currently get the
following splat:
I wouldn't say that nobody cares, it just hasn't bubbled up on
anyone's priority list yet (most developers aren't working on targets
that make heavy use of multilibs).
Pardon my theatrics :-)
But probably more importantly, this problem seems to not be triggering
on all multilib targets. For example, I just examined my tester's
build logs and couldn't see this on the H8/300 or V850 ports. Which
begs the question, why?
Are just in case, this is not running a subset using some stray
RUNTESTFLAGS.
Yes I'm curious to see why others are not seeing it. Could you rerun
upstream with following debug (and avoid -j when running the testsuite
just to serialize the logs - the problem does happen for -j runs too
though). Then in the logs we could see if init/finish get out of sync
around the culprit file (or my case at least)
--->
diff --git a/gcc/testsuite/lib/torture-options.exp
b/gcc/testsuite/lib/torture-options.exp
index dfb536d1d96c..95a6f818fded 100644
--- a/gcc/testsuite/lib/torture-options.exp
+++ b/gcc/testsuite/lib/torture-options.exp
@@ -22,6 +22,8 @@
proc torture-init { args } {
global torture_without_loops global_with_loops
+ send_user "\n\n=== torture-init\n"
+
if [info exists torture_without_loops] {
error "torture-init: torture_without_loops is not empty as
expected = \"${torture_without_loops}\""
}
@@ -116,6 +118,8 @@ proc set-torture-options { args } {
proc torture-finish { args } {
global torture_without_loops torture_with_loops
+ send_user "\n\n=== torture-finish\n"
+
if [info exists torture_without_loops] {
unset torture_without_loops
} else {
--->8---
FWIW I'd like to be able to test stuff cross-arch too (at least x86,
aarch64 and a few others).
Thx,
-Vineet
