So I resurrected our milkv pioneer over the weekend. While it had the
tell-tale signs of PCIE switch issues, it actually appears that the NMVE
drive was failing. I had an NVME that was going to be installed in a
different system, so I threw it into the Pioneer as a last ditch effort
to get it functional again. Voila! It's a happy camper (so far).
Naturally I don't like manual testing, so cobbled together a new target
for my tester. I forgot to update one field when doing that and as a
result it picked up prior test results from the job that runs on the BPI.
Comparing test results from a BPI to the Pioneer wouldn't normally be
interesting. We'd expect to see a whole bunch of tests disappear as the
Pioneer doesn't have all kinds of extensions that the BPI does (and that
does indeed happen).
As it turns out we have a handful of tests which need bitmanip to run,
but which don't restrict themselves to only run on appropriate hardware.
So we might as well fix that.
Given the Pioneer/BPI take 6/24 hours to cycle through respectively I
just spot checked the testsuite changes. Pushing to the trunk.
Jeff
commit f82227cc36a5abbe1926248780bb344327a15485
Author: Jeff Law <j...@ventanamicro.com>
Date: Mon Aug 11 08:13:51 2025 -0600
Don't run tests requiring "B" on designs without "B"
So I resurrected our milkv pioneer over the weekend. While we had the
tell-tale signs of PCIE switch issues, it actually appears that the NMVE
drive
was failing. I had an NVME that was going to be installed in a different
system, so I threw it into the Pioneer as a last ditch effort to get it
functional again. Voila! It's a happy camper (so far).
Naturally I don't like manual testing, so cobbled together a new target for
my
tester. I forgot to update one field when doing that and as a result it
picked
up testsuite prior test results from the job that runs on the BPI.
So comparing test results from a BPI to the Pioneer wouldn't normally be
interesting. We'd expect to see a whole bunch of tests disappear as the
Pioneer doesn't have all kinds of extensions that the BPI does (and that
does
indeed happen).
As it turns out we have a handful of tests which need bitmanip to run, but
which don't restrict themselves to only run on appropriate hardware. So we
might as well fix that.
Given the Pioneer/BPI take 6/24 hours to cycle through respectively I just
spot
checked the testsuite changes. Pushing to the trunk.
gcc/
* doc/sourcebuild.texi: Add riscv_b_ok and riscv_v_ok target
selectors.
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_riscv_b_ok): New.
* gcc.target/riscv/pr116085.c: Use new target selector.
* gcc.target/riscv/pr117690.c: Use new target selector.
* gcc.target/riscv/pr120333.c: Use new target selector.
* gcc.target/riscv/zba-shNadd-10.c: Use new target selector.
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index a9193040b37..c001e8ed683 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1,4 +1,4 @@
-@c Copyright (C) 2002-2025 Free Software Foundation, Inc.
+cc Copyright (C) 2002-2025 Free Software Foundation, Inc.
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
@@ -2563,6 +2563,12 @@ Test system has an integer register width of 64 bits.
@item riscv_a
Test target architecture has support for the A extension.
+@item riscv_b_ok
+Test target architecture can execute code with B extension enabled.
+
+@item riscv_v_ok
+Test target architecture can execute code with V extension enabled.
+
@item riscv_zaamo
Test target architecture has support for the zaamo extension.
diff --git a/gcc/testsuite/gcc.target/riscv/pr116085.c
b/gcc/testsuite/gcc.target/riscv/pr116085.c
index 998d82bd235..880f8354f8b 100644
--- a/gcc/testsuite/gcc.target/riscv/pr116085.c
+++ b/gcc/testsuite/gcc.target/riscv/pr116085.c
@@ -1,5 +1,4 @@
-/* { dg-do run } */
-/* { dg-require-effective-target rv64 } */
+/* { dg-do run { target { rv64 && riscv_b_ok } } } */
/* { dg-options "-march=rv64gc_zbb -mabi=lp64d -fno-ext-dce" } */
extern void abort (void);
diff --git a/gcc/testsuite/gcc.target/riscv/pr117690.c
b/gcc/testsuite/gcc.target/riscv/pr117690.c
index 9c06ab45ac8..d0784a1dfde 100644
--- a/gcc/testsuite/gcc.target/riscv/pr117690.c
+++ b/gcc/testsuite/gcc.target/riscv/pr117690.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { riscv64*-*-* } } } */
+/* { dg-do run { target { rv64 && riscv_b_ok } } } */
/* { dg-options "-march=rv64gc_zba_zbb -mabi=lp64d" } */
#define myconst 0x4fffaffb0fffefffUL;
diff --git a/gcc/testsuite/gcc.target/riscv/pr120333.c
b/gcc/testsuite/gcc.target/riscv/pr120333.c
index 17b376f3add..3417d22dc09 100644
--- a/gcc/testsuite/gcc.target/riscv/pr120333.c
+++ b/gcc/testsuite/gcc.target/riscv/pr120333.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { rv64 } } } */
+/* { dg-do run { target { rv64 && riscv_b_ok } } } */
/* { dg-additional-options "-march=rv64gcb -std=gnu23" } */
__attribute__ ((noipa)) _Bool
diff --git a/gcc/testsuite/gcc.target/riscv/zba-shNadd-10.c
b/gcc/testsuite/gcc.target/riscv/zba-shNadd-10.c
index 883cce271ca..f3a9ba93253 100644
--- a/gcc/testsuite/gcc.target/riscv/zba-shNadd-10.c
+++ b/gcc/testsuite/gcc.target/riscv/zba-shNadd-10.c
@@ -1,4 +1,4 @@
-/* { dg-do run { target { rv64 } } } */
+/* { dg-do run { target { rv64 && riscv_b_ok } } } */
/* { dg-options "-march=rv64gc_zba -mabi=lp64d -O2" } */
struct {
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 74355194b76..e8f88852591 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2254,6 +2254,32 @@ proc check_effective_target_riscv_xtheadvector { } {
}
+# Return 1 if we can execute code when using dg-add-options riscv_b
+
+proc check_effective_target_riscv_b_ok { } {
+ # If the target already supports zbb without any added options,
+ # we may assume we can execute just fine.
+ # Technically we should really check for zba/zbs too, but I haven't
+ # seen a design that implements a subset of zba/zbb/zbs yet.
+ if { [check_effective_target_riscv_zbb] } {
+ return 1
+ }
+
+ # check if we can execute bitmanip insns with the given hardware or
+ # simulator
+ set gcc_march [regsub {[[:alnum:]]*} [riscv_get_arch] &b]
+ if { [check_runtime ${gcc_march}_exec {
+ int main() { asm("sh2add t0, a0, a1"); return 0; } }
"-march=${gcc_march}"] } {
+ return 1
+ }
+
+ # Possible future extensions: If the target is a simulator, dg-add-options
+ # might change its config to make it allow vector insns, or we might use
+ # options to set special elf flags / sections to effect that.
+
+ return 0
+}
+
# Return 1 if we can execute code when using dg-add-options riscv_v
proc check_effective_target_riscv_v_ok { } {
