This is the mail archive of the mailing list for the libstdc++ project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

>From '2002-11-24 05:00 UTC' to '2002-12-09 04:00 UTC' appeared:
FAIL: 23_containers/ 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/ (test03): Add.

A file like 23_containers/ 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/ or
testsuite/23_containers/  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/
failure is a "real" regression.  I'll add a PR for this.

brgds, H-P

PS.  To test libstdc++-v3 with
<URL:>, you need to patch
libstdc++-v3/testsuite/ like in

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]