I'm consistently seeing this time out when regtesting make check-parallel. Is it unavoidable withing the current infrastructure? Besides slowing down the testing itself (not a very big issue, momentarily, I will commit an hack for this), seems a quite puzzling behavior to me: if parallel-mode runs orders of magnitude slower than serial-mode, shouldn't in principle at minimum fall back to the latter?
Maybe rather an endless loop.
My impression is that for some reason it's just slow, very slow: with TEST_DEPTH=10 it completes in a decent amount of time...
Paolo, you were right, it was just the fallback switch missing for this case. And since this specific test issues many thousands of calls with very small input, the overhead was very noticeable. Patch upcoming...
Excellent. If possible, I would suggest removing my temporary hack from the testcase together with the parallel-mode patch.
Subject: Bug 42712 Author: singler Date: Tue Jan 19 11:18:03 2010 New Revision: 156036 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156036 Log: 2010-01-19 Johannes Singler <singler@kit.edu> PR libstdc++/42712 * include/parallel/settings.h (_Settings): Add search_minimal_n. * include/parallel/algo.h (__search_switch): Add serial fallback for too small inputs. (__search_n_switch): Likewise. Call serial fallback on higher level to gain special treatment for __count 0 or 1. * testsuite/25_algorithms/search_n/iterator.cc: Reenable full test depth for parallel mode. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/algo.h trunk/libstdc++-v3/include/parallel/settings.h trunk/libstdc++-v3/testsuite/25_algorithms/search_n/iterator.cc
Confirmed fixed, thanks!