On Tue, 26 May 2020, Rob Savoye wrote:
> > I'll run some RISC-V remote GCC/GDB testing and compare results for
> > DejaGnu 1.6/1.6.1 vs trunk. It will take several days though, as it takes
> > many hours to go through these testsuite runs.
>
> That'd be great. I'd rather push out a stable release, than have to
> fix bugs right after it gets released.
I have completed GCC and GDB testing now with the `riscv64-linux-gnu'
target and the `x86_64-linux-gnu' host.
GDB results obtained with real hardware are looking good, with the usual
fluctuation due to intermittent failures caused by races in test cases:
@@ -63343,8 +63344,8 @@
=== gdb Summary ===
-# of expected passes 59902
-# of unexpected failures 778
+# of expected passes 59900
+# of unexpected failures 781
# of unexpected successes 2
# of expected failures 48
# of unknown successes 5
Similarly GCC test results taken with QEMU in the user emulation mode
show a couple of intermittent discrepancies (not present on a rerun)
within the libgo testsuite only:
@@ -912,12 +912,12 @@ Schedule of variations:
Running target qemu-user-lp64d
Running .../libgo/testsuite/libgo.testmain/testmain.exp ...
-FAIL: database/sql
+PASS: database/sql
=== libgo Summary ===
-# of unexpected failures 1
-Test run by macro on Thu Jun 4 04:29:42 2020
+# of expected passes 1
+Test run by macro on Wed Jun 3 01:38:10 2020
Target is riscv64-unknown-linux-gnu
Host is riscv64-unknown-linux-gnu
Build is x86_64-pc-linux-gnu
and:
@@ -2239,12 +2239,12 @@ Schedule of variations:
Running target qemu-user-lp64d
Running .../libgo/testsuite/libgo.testmain/testmain.exp ...
-PASS: net/http/pprof
+FAIL: net/http/pprof
=== libgo Summary ===
-# of expected passes 1
-Test run by macro on Thu Jun 4 02:42:17 2020
+# of unexpected failures 1
+Test run by macro on Tue Jun 2 23:54:18 2020
Target is riscv64-unknown-linux-gnu
Host is riscv64-unknown-linux-gnu
Build is x86_64-pc-linux-gnu
(the testsuite is run in a peculiar manner in the remote case, hence the
individual per-test summaries) and are otherwise identical.
However native `x86_64-linux-gnu' GDB testing does not work at all; all
it gets is:
get_compiler_info: default_target_compile: No compiler to compile with
get_compiler_info: compiler_info not provided
get_compiler_info: got unexpected diagnostics
get_compiler_info: unknown
gdb compile failed, default_target_compile: No compiler to compile with
Conversely all things being equal DejaGnu 1.6 finds native `/usr/bin/gcc'
just fine:
get_compiler_info: set compiler_info "unknown"
get_compiler_info: set compiler_info [join {gcc 9 2 1} -]
get_compiler_info: gcc-9-2-1
and in the verbose mode also:
Checking /home/macro/bin for gcc
Checking /home/macro/bin for gcc
Checking /usr/local/bin for gcc
Checking /usr/bin for gcc
Choosing /usr/bin/gcc
I ran a quick bisection and the culprit turned out to be:
ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
commit ba60272a5ac6f6a7012acca03f596a6ed003f044
Author: Jacob Bachmeyer <jcb62281+...@gmail.com>
Date: Mon May 25 08:40:46 2020 -0600
Establish a default C compiler by evaluating [find_gcc] if no other
compiler is given.
So this regression has to be fixed before any new release is made.
HTH,
Maciej
