public inbox for libstdc++-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc r11-4974] libstdc++: Add -pthread options to std::future polling test
@ 2020-11-13 11:01 Jonathan Wakely
0 siblings, 0 replies; only message in thread
From: Jonathan Wakely @ 2020-11-13 11:01 UTC (permalink / raw)
To: gcc-cvs, libstdc++-cvs
https://gcc.gnu.org/g:8c4e33d2032ab150748ea2fe1df2b1c00652a338
commit r11-4974-g8c4e33d2032ab150748ea2fe1df2b1c00652a338
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Fri Nov 13 10:04:33 2020 +0000
libstdc++: Add -pthread options to std::future polling test
For linux targets this test doesn't need -lpthread because it only uses
atomics, but for all other targets std::call_once still needs pthreads.
Add the necessary test directives to make that work.
The timings in this test might be too fragile or too target-specific, so
it might need to be adjusted in future, or restricted to only run on
specific targets. For now I've increased the allowed ratio between
wait_for calls before and after the future is made ready, because it was
failing with -O3 -march=native sometimes.
libstdc++-v3/ChangeLog:
* testsuite/30_threads/future/members/poll.cc: Require gthreads
and add -pthread for targets that require it. Relax required
ratio of wait_for calls before/after the future is ready.
Diff:
---
.../testsuite/30_threads/future/members/poll.cc | 40 ++++++++++++----------
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/libstdc++-v3/testsuite/30_threads/future/members/poll.cc b/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
index 54580579d3a..fff9bea899c 100644
--- a/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
+++ b/libstdc++-v3/testsuite/30_threads/future/members/poll.cc
@@ -17,6 +17,8 @@
// { dg-options "-O3" }
// { dg-do run { target c++11 } }
+// { dg-additional-options "-pthread" { target pthread } }
+// { dg-require-gthreads "" }
#include <future>
#include <chrono>
@@ -51,31 +53,31 @@ int main()
start = chrono::high_resolution_clock::now();
for(int i = 0; i < iterations; i++)
- f.wait_until(chrono::system_clock::time_point());
+ f.wait_until(chrono::system_clock::time_point::min());
stop = chrono::high_resolution_clock::now();
- double wait_until_sys_epoch __attribute__((unused))
- = print("wait_until(system_clock epoch)", stop - start);
+ double wait_until_sys_min __attribute__((unused))
+ = print("wait_until(system_clock minimum)", stop - start);
start = chrono::high_resolution_clock::now();
for(int i = 0; i < iterations; i++)
- f.wait_until(chrono::steady_clock::time_point());
+ f.wait_until(chrono::steady_clock::time_point::min());
stop = chrono::high_resolution_clock::now();
- double wait_until_steady_epoch __attribute__((unused))
- = print("wait_until(steady_clock epoch", stop - start);
+ double wait_until_steady_min __attribute__((unused))
+ = print("wait_until(steady_clock minimum)", stop - start);
start = chrono::high_resolution_clock::now();
for(int i = 0; i < iterations; i++)
- f.wait_until(chrono::system_clock::time_point::min());
+ f.wait_until(chrono::system_clock::time_point());
stop = chrono::high_resolution_clock::now();
- double wait_until_sys_min __attribute__((unused))
- = print("wait_until(system_clock minimum)", stop - start);
+ double wait_until_sys_epoch __attribute__((unused))
+ = print("wait_until(system_clock epoch)", stop - start);
start = chrono::high_resolution_clock::now();
for(int i = 0; i < iterations; i++)
- f.wait_until(chrono::steady_clock::time_point::min());
+ f.wait_until(chrono::steady_clock::time_point());
stop = chrono::high_resolution_clock::now();
- double wait_until_steady_min __attribute__((unused))
- = print("wait_until(steady_clock minimum)", stop - start);
+ double wait_until_steady_epoch __attribute__((unused))
+ = print("wait_until(steady_clock epoch", stop - start);
p.set_value(1);
@@ -85,19 +87,19 @@ int main()
stop = chrono::high_resolution_clock::now();
double ready = print("wait_for when ready", stop - start);
- // polling before ready with wait_for(0s) should be almost as fast as
+ // Polling before ready with wait_for(0s) should be almost as fast as
// after the result is ready.
- VERIFY( wait_for_0 < (ready * 10) );
+ VERIFY( wait_for_0 < (ready * 30) );
+
+ // Polling before ready using wait_until(min) should not be terribly slow.
+ VERIFY( wait_until_sys_min < (ready * 100) );
+ VERIFY( wait_until_steady_min < (ready * 100) );
// The following two tests fail with GCC 11, see
// https://gcc.gnu.org/pipermail/libstdc++/2020-November/051422.html
#if 0
- // polling before ready using wait_until(epoch) should not be terribly slow.
+ // Polling before ready using wait_until(epoch) should not be terribly slow.
VERIFY( wait_until_sys_epoch < (ready * 100) );
VERIFY( wait_until_steady_epoch < (ready * 100) );
#endif
-
- // polling before ready using wait_until(min) should not be terribly slow.
- VERIFY( wait_until_sys_min < (ready * 100) );
- VERIFY( wait_until_steady_min < (ready * 100) );
}
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-11-13 11:01 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-13 11:01 [gcc r11-4974] libstdc++: Add -pthread options to std::future polling test Jonathan Wakely
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).