https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124290
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot > Uni-Bielefeld.DE> --- >> --- Comment #1 from Tomasz Kamiński <tkaminsk at gcc dot gnu.org> --- >> Yes, adding `dg-timeout-factor` seem as reasonable solution, and few sibling >> test in the same directory already have them. >> >> For the splitting, the test were already split to test one layout per file, >> so >> without large refactoring of them, I do not think further splitting is >> feasible. >> >> Would you mind posting a patch with factors that make test pass for you? > > Sure, I'll give it a try. I'll check if there's a specific set where > this happens repeatedly or if I just add dg-timeout-factor 2 to all of > them (so it won't be forgotten for future tests ;-) After all, the > tests that time out varies from build to build. It seems I need to go as high as a timeout factor of 4 to make the tests PASS reliably. Checking on an unloaded system, the builds take between 3.5 and 4.5 minutes to complete, dangerously close to the default timeout of 5 minutes. I wonder why this is so slow, though: repeating the compilation on a Linux/sparc64 system gives compile times about 1m43s instead...
