https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119508
--- Comment #24 from Thomas Schwinge <tschwinge at gcc dot gnu.org> --- (In reply to Owen A. from comment #23) > (In reply to Thomas Schwinge from comment #22) > > (In reply to Owen A. from comment #12) > > > I can't replicate this on my end anymore -- is it still present on x86_64? > > > > That's a surprising statement, given that I clearly described how to > > reproduce the issue: > > > > (In reply to myself from comment #11) > > > Running 'check-gcc-rust' with '-j1' looks reasonable. But, for example, > > > comparing a '-j1' run to a '-j2' run, I see: [...] > I've tried -j2, -j3, -j64, etc, on both trunk and > https://github.com/Rust-GCC/gccrs -- I can't reproduce it. I'd like to understand what's happening, what's different. Are these '-jN' for 'make -jN check-gcc-rust', or for 'make -jN check'? The former is what I was talking about; the latter includes 'make -jM check-gcc-rust', with 'M <= N'; typically 'M << N' ('M' much less than 'N'). If the latter, you could examine '[build]/gcc/testsuite/rust*' directories/content, to see what the actual "'-jM'" parallelism is that's used for 'check-gcc-rust'. > I'm starting to think that, for some reason, my machine is running tests > with parallel testing effectively disabled. That seems unlikely to me? If parallel testing isn't working, you should see system load ~1, otherwise ~N. (..., and again, see '[build]/gcc/testsuite/*' directories/content for the details. -- You are receiving this mail because: You are on the CC list for the bug.
