https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114886
Bug ID: 114886 Summary: gm2 testsuite arbitrarily reduces timeouts Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- When bootstrapping the gcc-14 branch on sparc-sun-solaris2.11, quite a number of gm2 tests FAILed due to timeouts. I had seen this before and could trace this to the gm2 testsuite reducing way beyond the default of 300 seconds (sometimes as low as 10 seconds). I think this is badly misguided for a couple of reasons: * If a test completes (PASS or FAIL) within the reduced reduced timeout, it will do so with the default timeout, too. * If a test takes either longer than the default timeout (either because compilation of execution is particularly slow or because some step loops indefinitely), reducing the timeout would give a result earlier. However, I've rarely if ever seen such a case in all my testing. * If a test takes longer than the reduced timeout, it will fail while it would pass just fine with the default timeout. * Using hardcoded timeouts is always wrong: while the values currenly used may work one some particular target, it will cause failures on systems that are either slower or under higher load. Besides, it is possible to globally change the derfault in some expect snippet (like global board_info set board_info(unix,gcc,timeout) 600 (even differently per multilib if desired). IMO this whole approach is completely misguided, has very little benefit even in the best case, and demonstrably introduces failures that wouldn't exist without it. I'm attaching my current hack for reference, but it's completely inappropriate as is. It only identifies some (all?) places that need changing.