Regression(?) on the 3.2 branch: 23_containers/vector_capacity.cc execution test

[Hans-Peter Nilsson]

>From '2002-11-24 05:00 UTC' to '2002-12-09 04:00 UTC' appeared:
FAIL: 23_containers/vector_capacity.cc execution test
on the 3.2 branch for all newlib targets (mmix-knuth-mmixware,
cris-axis-elf, v850-unknown-elf, m32r-unknown-elf,
mn10300-unknown-elf, arm-unknown-elf, powerpc-unknown-eabisim)
with my spurious multi-target testing.  The test does not fail
on cris-axis-linux-gnu (statically linked), so perhaps your
favorite GNU/Linux host does not show the failure.  Some targets
time out the test, some fail with messages about invalid
instructions or invalid memory accesses.

It doesn't help bug-tracking, that the way the libstdc++-v3
project adds to the testsuite by *modifying* existing named
test-files.  I see ChangeLog entries in this time-period like:

	* testsuite/23_containers/vector_capacity.cc (test03): Add.

A file like 23_containers/vector_capacity.cc counts as *one*
test: it fails or succeeds as one.  The sub-tests within it are
not discernible without unduly extra work.

Can the libstdc++-v3 project please consider adding *files* when
adding to the test-suite?  For example, the added test could
have been testsuite/23_containers/vector_capacity/03.cc or
testsuite/23_containers/vector_capacity-03.cc.  Framework in a
header file or library file.  I see you have a test-specific
library file already.

I still don't know whether the 23_containers/vector_capacity.cc
failure is a "real" regression.  I'll add a PR for this.

brgds, H-P

PS.  To test libstdc++-v3 with
<URL:http://gcc.gnu.org/simtest-howto.html>, you need to patch
libstdc++-v3/testsuite/Makefile.in like in
<URL:http://gcc.gnu.org/ml/gcc/2002-04/msg01187.html>.