From: Jonathan Wakely <jwakely@redhat.com>
To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Subject: [RFC] Decrease default timeout for libstdc++ tests to 6 minutes
Date: Fri, 27 Nov 2020 16:13:30 +0000 [thread overview]
Message-ID: <20201127161330.GT1312820@redhat.com> (raw)
The default for the GCC testsuite is 300, i.e. 5 minutes, which is the
same as the DejaGnu default.
Libstdc++ overrides this to 600, i.e. 10 minutes.
This seems ridiculously long. If any test takes that long on modern
hardware, something is wrong. We've seen this a lot recently with
buggy tests, and waiting for them to FAIL is tedious.
I've already made libstdc++.exp respect the user's setting in
~/.dejagnurc or the global site.exp file. This means anybody testing
on slow simulators or old hardware can choose their own timeout.
I've added dg-timeout-factor to the slowest std::regex tests and have
a patch to do it for the PSTL tests, which both take far too long to
compile. That means you can choose a sensible timeout appropriate for
most tests (e.g. 60 seconds) and not get spurious failures from the
few dozen tests which are just very slow.
I'd like to change the default to 6 minutes. If that goes well, I'd
like to lower it even further.
The main benefit of this will be that buggy tests which hang will get
killed sooner, so we waste less time waiting for the inevitable
timeout.
Here's the proposed patch for completeness:
--- a/libstdc++-v3/testsuite/lib/libstdc++.exp
+++ b/libstdc++-v3/testsuite/lib/libstdc++.exp
@@ -248,7 +248,7 @@ proc libstdc++_init { testfile } {
# Set the default timeout for v3 tests.
# You can override this in ~/.dejagnurc or a .exp file named by $DEJAGNU.
if {![info exists tool_timeout]} {
- set tool_timeout 600
+ set tool_timeout 360
}
# Default settings.
next reply other threads:[~2020-11-27 16:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-27 16:13 Jonathan Wakely [this message]
2020-11-27 20:17 ` Christophe Lyon
2020-11-30 14:58 ` Jonathan Wakely
2020-12-01 9:45 ` Christophe Lyon
2020-12-01 10:52 ` Jonathan Wakely
2020-12-02 12:35 ` Jonathan Wakely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201127161330.GT1312820@redhat.com \
--to=jwakely@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=libstdc++@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).