[RFA:] Make 23_containers/set/modifiers/16728.cc not time out nonnatively

[Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>]

:ADDPATCH libstdc++ testsuite:

Whenever I test cris-axis-elf (using a simulator) certain
libstdc++ tests time out, some of them depending on the host
system load.  That's not until now been important enough to
worry about, but as I now have an autoregtester in place (no
worries, it reports to me only :) those timeouts translate to
time wasted that would have been used for the next round
(probably more like one or two more full rounds).  Currently,
about ten tests, all in the libstdc++ testsuite time out for (at
a glance) different reasons.  Here's a fix that may generally
apply to many of them: don't do as much in the cross-test case
as in the native case.

Regarding this test, 23_containers/set/modifiers/16728.cc, I'm
not even sure what purpose it has.  It says "the goal with this
application is to compare the performance between different
std::allocator implementations" but at least in the testsuite it
doesn't (compare any performance).  All it seems to do is
churning memory allocations, and I don't see any sign of
checking that it does anything correctly, other than hopefully
trapping miscompilations and bugs in the allocator.  The URLs in
the test also hint that this test would be used together with
"time" to compare allocator performance, but that's not done;
all it does in the testsuite is churn churn churn.

It has some interesting nonlinear behaviour: with the
src/sim/cris simulator and cris-axis-elf on a Opteron 150 2.4GHz:
Iterations	Time (user)
<=5		0.02s
10		0.03s
100		0.68s
200		2.58s
300		5.59s
400		9.87s
500		15.32s
600		22.27s
700		33.43s
800		58.27s
900		97.01s
1000		(was still running after 5.8h)
10000		(was still running after 10h)

It runs pretty quickly natively on a x86_64 host, so those
figures don't translate very well; maybe at 10 M iterations
you'd see thrashing there.

Anyway, I can't see why the figure 10000 would be magical, might
as well make it 1000 times less for cross environments as
follows.  Tested x86_64-unknown-linux-gnu native and cross to
cris-axis-elf, making sure the -DITERATIONS=10 happens for the
latter, not the former.

Ok to commit?

If so, perhaps I can get preapproval for similar changes to
other libstdc++ tests?

libstdc++-v3:
        * testsuite/23_containers/set/modifiers/16728.cc: Use only 10
        iterations for non-native targets.

Index: testsuite/23_containers/set/modifiers/16728.cc
===================================================================
--- testsuite/23_containers/set/modifiers/16728.cc	(revision 121581)
+++ testsuite/23_containers/set/modifiers/16728.cc	(working copy)
@@ -38,8 +38,14 @@ using namespace std;
 
 typedef int test_type;
 
+// This can take extremely long on simulators, timing out the test.
+// { dg-options "-DITERATIONS=10" { target { ! native } } }
+#ifndef ITERATIONS
+#define ITERATIONS 10000
+#endif
+
 // The number of iterations to be performed.
-int iterations = 10000;
+int iterations = ITERATIONS;
 
 // The number of values to insert in the container, 32 will cause 5
 // (re)allocations to be performed (sizes 4, 8, 16, 32 and 64)

brgds, H-P