[PATCH] VAX/testsuite: Remove notsi comparison elimination regressions

Maciej W. Rozycki macro@orcam.me.uk
Tue Jan 26 16:15:06 GMT 2021


On Mon, 11 Jan 2021, Jeff Law wrote:

> I think most are posting the stdout from the check run.   So we don't
> generally get all the pass/xfail messages, but we do get fail/xpass
> messages.  They don't need to be triaged or anything.

 I now have the results, though I had to trim them by hand from the noise 
to match postings to the mailing lists.  This might have been because I 
used to combine stdout and stderr output of test runs into a single file 
as a matter of routine and didn't think of separating the streams on this 
occasion.

 Still at 2.4MiB+ the size of the log is IIUC well beyond the limit of the 
mailing list, so sadly I won't be able to post it.  This is mostly due to 
the highly verbose nature of `FAIL: outputs [...]' messages from the `gcc' 
testsuite.

 Overall with the timeout increased to 7200 seconds testing took almost 
7.5 days to complete unattended, that is without killing runaway processes 
from `libstdc++' testing.  These were the test cases that timed out 
regardless, but eventually did run to completion:

FAIL: 27_io/basic_istream/ignore/char/94749.cc execution test
FAIL: 27_io/basic_istream/ignore/wchar_t/94749.cc execution test

and therefore would require a higher timeout to complete, whether
successfully or not.  These have genuinely hung:

FAIL: 20_util/hash/chi2_q_uniform_random.cc execution test
FAIL: 30_threads/barrier/arrive.cc execution test
FAIL: 30_threads/barrier/arrive_and_drop.cc execution test
FAIL: 30_threads/barrier/arrive_and_wait.cc execution test
FAIL: 30_threads/barrier/completion.cc execution test

beating on the CPU and consuming its full power:

  PID TTY STAT       TIME COMMAND
 8666 ?   Rl   1513:06.00 /scratch/vol0/vax-netbsd-upstream/obj/gcc/vax-netbsdelf/libstdc++-v3/testsuite/completion.exe
16681 ?   Rl   1594:12.00 /scratch/vol0/vax-netbsd-upstream/obj/gcc/vax-netbsdelf/libstdc++-v3/testsuite/arrive_and_drop.exe (arrive_and_drop.)
18113 ?   Rl   1566:02.00 /scratch/vol0/vax-netbsd-upstream/obj/gcc/vax-netbsdelf/libstdc++-v3/testsuite/arrive_and_wait.exe (arrive_and_wait.)
28671 ?   Rl   1646:19.00 /scratch/vol0/vax-netbsd-upstream/obj/gcc/vax-netbsdelf/libstdc++-v3/testsuite/arrive.exe
28940 ?   R    5111:20.00 /scratch/vol0/vax-netbsd-upstream/obj/gcc/vax-netbsdelf/libstdc++-v3/testsuite/chi2_q_uniform_random.exe (chi2_q_uniform_r)

I think it makes it vital that these hangs are investigated and the cause 
of the problem found and addressed as a matter of priority if we want to 
be able to reliably run unattended GCC verification of the VAX/NetBSD 
configuration.  I'll see if I can dedicate some time to doing that, but I 
have other commitments now too.

 NB in the recent failure of linux-mips.org I have lost some recent e-mail 
and may not be able to refer to or reply to some messages, and sadly our 
new mailing list archives do not permit the extraction of raw messages.  
Some information might be available from external sources, e.g. full raw 
messages that contain patches have been retained in patchwork and message 
IDs can be extracted from mail-archive.com archives.  This is actually how 
I reconstructed this reply.  The failure does not affect the VAX effort 
itself in any way though, as completely different systems have been used 
for that.

  Maciej


More information about the Gcc-patches mailing list