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
