diff mbox series

libstdc++ testsuite: Increase lwg3464.cc timeout factors to 20

Message ID 20220130013541.A127620418@pchp3.se.axis.com
State New
Headers show
Series libstdc++ testsuite: Increase lwg3464.cc timeout factors to 20 | expand

Commit Message

Hans-Peter Nilsson Jan. 30, 2022, 1:35 a.m. UTC 
These tests have always been failing for my cris-elf
autotester running a simulator; they take about 20 minutes
each, compared to the timeout of 720 seconds, doubled
because they timed out in another simulator setup.

They are the *only* libstdc++ tests that timeout for my
setup so I thought this'd be best fixed in the testsuite
rather than a local timeout setting (in e.g. the baseboard
file).  And, better make it an increase that counts.  Or,
maybe they're actually needlessly excessive? FWIW, running
the whole libstdc++ testsuite for this target takes 2h40min.

Ok?

	* testsuite/27_io/basic_istream/get/char/lwg3464.cc: Increase
	timeout factor to 20.
	* testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc: Likewise.
---
 libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc  | 2 +-
 .../testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc        | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

Comments

Jonathan Wakely Jan. 30, 2022, 8:32 a.m. UTC | #1 
On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++, <
libstdc++@gcc.gnu.org> wrote:

> These tests have always been failing for my cris-elf
> autotester running a simulator; they take about 20 minutes
> each, compared to the timeout of 720 seconds, doubled
> because they timed out in another simulator setup.
>
> They are the *only* libstdc++ tests that timeout for my
> setup so I thought this'd be best fixed in the testsuite
> rather than a local timeout setting (in e.g. the baseboard
> file).  And, better make it an increase that counts.  Or,
> maybe they're actually needlessly excessive?


They are testing behaviour when a counter overflows, so they have to read
that many bytes. Making them do less work would not test that condition.

But there is nothing target-specific in that code, so it should be fine to
disable them for simulators. They're already disabled for LP64 because
overflowing the 64-bit counter would take forever.

I think that would be better than letting them potentially run for 40
minutes even on real hardware.
diff mbox series

Patch

diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
index f426ff7dd867..69612375cba0 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
@@ -16,7 +16,7 @@ 
 // <http://www.gnu.org/licenses/>.
 
 // { dg-do run { target { ! lp64 } } }
-// { dg-timeout-factor 2 }
+// { dg-timeout-factor 20 }
 
 #include <istream>
 #include <streambuf>
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
index 4be6beb2310f..5f07c6d9880d 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
@@ -16,7 +16,7 @@ 
 // <http://www.gnu.org/licenses/>.
 
 // { dg-do run { target { ! lp64 } } }
-// { dg-timeout-factor 2 }
+// { dg-timeout-factor 20 }
 
 #include <istream>
 #include <streambuf>