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.
