This test often times out, especially on machines with a large number of
cores when the tests are run with a lot of parallel jobs. I suspect that
TBB creates a lot of threads due to std::hardware_concurrency() being a
large number, but because most cores are already busy running other
tests (due to `make -jN check` with large N) the system gets
oversubscribed. In Debug Mode, the testcase runs much slower, and often
times out.
It's probably fine to just test with fewer iterations when Debug Mode is
active.
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/pstl/alg_sorting/minmax_element.cc:
Reduce iterations for debug mode.
---
Tested x86_64-linux. Pushed to trunk.
.../25_algorithms/pstl/alg_sorting/minmax_element.cc | 4 ++++
1 file changed, 4 insertions(+)
diff --git
a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/minmax_element.cc
b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/minmax_element.cc
index e4bd435d1926..51bdeaa96a13 100644
--- a/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/minmax_element.cc
+++ b/libstdc++-v3/testsuite/25_algorithms/pstl/alg_sorting/minmax_element.cc
@@ -189,7 +189,11 @@ int
main()
{
using TestUtils::float64_t;
+#ifndef _GLIBCXX_DEBUG
const std::size_t N = 100000;
+#else
+ const std::size_t N = 10000;
+#endif
for (std::size_t n = 0; n < N; n = n < 16 ? n + 1 : size_t(3.14159 * n))
{
--
2.54.0
