https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #50 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to lucier from comment #49) > > > Running > > > /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/ > > > conformance.exp ... > > > WARNING: program timed out. > > > > There's not quite enough information here - it would be useful to know which > > test(s) timed out - running "make check -jN -k" (where N is some sensible > > number for the cores on your machine) would help since that will then print > > which tests timeout. > > I had previously tried "make -j20 -k check" and "make -j30 -k check", which > both gave the same "WARNING: program timed out." message, but where, > precisely, it timed out I couldn't tell. That's why I did it serially, let > it run for a few days, and that's the last thing that printed, immediately > after > > Running > /Users/lucier/programs/gcc/gcc-mainline/libstdc++-v3/testsuite/libstdc++-dg/ > conformance.exp ... hmm, there was a modification made to the testsuite output that relates timeouts to the test that failed. However there are buggy versions of expect on some darwin versions, which might well defeat that. I have a patched version of expect which I use in conjunction with dejagnu 1.6.2 and tcl-8.6(.9). If you look at x86_64-apple-darwin19/libstdc++/testsuite/libstdc++.log, then perhaps you can see the last test that was run in the serialised case. FWIW I see some timeout fails with unpatched master on x86_64-darwin19 (on two systems, one with corei5 and one with xeon w) - threads/barrier and randomly threads/latch. There are some known limitations with the implementations there that are planned to be addressed in GCC12.
