1 <section xmlns="http://docbook.org/ns/docbook" version="5.0"
2 xml:id="manual.intro.setup.test" xreflabel="Testing">
3 <?dbhtml filename="test.html"?>
5 <info><title>Test</title>
32 The libstdc++ testsuite includes testing for standard conformance,
33 regressions, ABI, and performance.
36 <section xml:id="test.organization" xreflabel="Test Organization"><info><title>Organization</title></info>
39 <section xml:id="test.organization.layout" xreflabel="Directory Layout"><info><title>Directory Layout</title></info>
43 The directory <emphasis>libsrcdir/testsuite</emphasis> contains the
44 individual test cases organized in sub-directories corresponding to
45 chapters of the C++ standard (detailed below), the dejagnu test
46 harness support files, and sources to various testsuite utilities
47 that are packaged in a separate testing library.
51 All test cases for functionality required by the runtime components
52 of the C++ standard (ISO 14882) are files within the following
73 In addition, the following directories include test files:
77 tr1 Tests for components as described by the Technical Report on Standard Library Extensions (TR1).
78 backward Tests for backwards compatibility and deprecated features.
79 demangle Tests for __cxa_demangle, the IA 64 C++ ABI demangler
80 ext Tests for extensions.
81 performance Tests for performance analysis, and performance regressions.
85 Some directories don't have test files, but instead contain
86 auxiliary information:
90 config Files for the dejagnu test harness.
91 lib Files for the dejagnu test harness.
92 libstdc++* Files for the dejagnu test harness.
93 data Sample text files for testing input and output.
94 util Files for libtestc++, utilities and testing routines.
98 Within a directory that includes test files, there may be
99 additional subdirectories, or files. Originally, test cases
100 were appended to one file that represented a particular section
101 of the chapter under test, and was named accordingly. For
102 instance, to test items related to <code> 21.3.6.1 -
103 basic_string::find [lib.string::find]</code> in the standard,
104 the following was used:
110 However, that practice soon became a liability as the test cases
111 became huge and unwieldy, and testing new or extended
112 functionality (like wide characters or named locales) became
113 frustrating, leading to aggressive pruning of test cases on some
114 platforms that covered up implementation errors. Now, the test
115 suite has a policy of one file, one test case, which solves the
116 above issues and gives finer grained results and more manageable
117 error debugging. As an example, the test case quoted above
121 21_strings/basic_string/find/char/1.cc
122 21_strings/basic_string/find/char/2.cc
123 21_strings/basic_string/find/char/3.cc
124 21_strings/basic_string/find/wchar_t/1.cc
125 21_strings/basic_string/find/wchar_t/2.cc
126 21_strings/basic_string/find/wchar_t/3.cc
130 All new tests should be written with the policy of one test
131 case, one file in mind.
136 <section xml:id="test.organization.naming" xreflabel="Naming Conventions"><info><title>Naming Conventions</title></info>
140 In addition, there are some special names and suffixes that are
141 used within the testsuite to designate particular kinds of
148 <emphasis>_xin.cc</emphasis>
151 This test case expects some kind of interactive input in order
152 to finish or pass. At the moment, the interactive tests are not
153 run by default. Instead, they are run by hand, like:
156 g++ 27_io/objects/char/3_xin.cc
157 cat 27_io/objects/char/3_xin.in | a.out
162 <emphasis>.in</emphasis>
165 This file contains the expected input for the corresponding <emphasis>
166 _xin.cc</emphasis> test case.
171 <emphasis>_neg.cc</emphasis>
174 This test case is expected to fail: it's a negative test. At the
175 moment, these are almost always compile time errors.
180 <emphasis>char</emphasis>
183 This can either be a directory name or part of a longer file
184 name, and indicates that this file, or the files within this
185 directory are testing the <code>char</code> instantiation of a
191 <emphasis>wchar_t</emphasis>
194 This can either be a directory name or part of a longer file
195 name, and indicates that this file, or the files within this
196 directory are testing the <code>wchar_t</code> instantiation of
197 a template. Some hosts do not support <code>wchar_t</code>
198 functionality, so for these targets, all of these tests will not
204 <emphasis>thread</emphasis>
207 This can either be a directory name or part of a longer file
208 name, and indicates that this file, or the files within this
209 directory are testing situations where multiple threads are
215 <emphasis>performance</emphasis>
218 This can either be an enclosing directory name or part of a
219 specific file name. This indicates a test that is used to
220 analyze runtime performance, for performance regression testing,
221 or for other optimization related analysis. At the moment, these
222 test cases are not run by default.
231 <section xml:id="test.run" xreflabel="Running the Testsuite"><info><title>Running the Testsuite</title></info>
234 <section xml:id="test.run.basic"><info><title>Basic</title></info>
238 You can check the status of the build without installing it
239 using the dejagnu harness, much like the rest of the gcc
241 <programlisting> make check</programlisting>
242 <para>in the <emphasis>libbuilddir</emphasis> directory.</para>
244 <programlisting> make check-target-libstdc++-v3</programlisting>
245 <para>in the <emphasis>gccbuilddir</emphasis> directory.
249 These commands are functionally equivalent and will create a
250 'testsuite' directory underneath
251 <emphasis>libbuilddir</emphasis> containing the results of the
252 tests. Two results files will be generated: <emphasis>
253 libstdc++.sum</emphasis>, which is a PASS/FAIL summary for each
254 test, and <emphasis>libstdc++.log</emphasis> which is a log of
255 the exact command line passed to the compiler, the compiler
256 output, and the executable output (if any).
260 Archives of test results for various versions and platforms are
261 available on the GCC website in the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/gcc-4.3/buildstat.html">build
262 status</link> section of each individual release, and are also
263 archived on a daily basis on the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/ml/gcc-testresults/current">gcc-testresults</link>
264 mailing list. Please check either of these places for a similar
265 combination of source version, operating system, and host CPU.
269 <section xml:id="test.run.variations"><info><title>Variations</title></info>
272 There are several options for running tests, including testing
273 the regression tests, testing a subset of the regression tests,
274 testing the performance tests, testing just compilation, testing
275 installed tools, etc. In addition, there is a special rule for
276 checking the exported symbols of the shared library.
279 To debug the dejagnu test harness during runs, try invoking with a
280 specific argument to the variable RUNTESTFLAGS, as below.
284 make check-target-libstdc++-v3 RUNTESTFLAGS="-v"
292 make check-target-libstdc++-v3 RUNTESTFLAGS="-v -v"
296 To run a subset of the library tests, you will need to generate
297 the <emphasis>testsuite_files</emphasis> file by running
298 <command>make testsuite_files</command> in the
299 <emphasis>libbuilddir/testsuite</emphasis> directory, described
300 below. Edit the file to remove the tests you don't want and
301 then run the testsuite as normal.
305 There are two ways to run on a simulator: set up DEJAGNU to point to a
306 specially crafted site.exp, or pass down --target_board flags.
310 Example flags to pass down for various embedded builds are as follows:
314 --target=powerpc-eabism (libgloss/sim)
315 make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=powerpc-sim"
317 --target=calmrisc32 (libgloss/sid)
318 make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=calmrisc32-sid"
320 --target=xscale-elf (newlib/sim)
321 make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=arm-sim"
325 Also, here is an example of how to run the libstdc++ testsuite
326 for a multilibed build directory with different ABI settings:
330 make check-target-libstdc++-v3 RUNTESTFLAGS='--target_board \"unix{-mabi=32,,-mabi=64}\"'
334 You can run the tests with a compiler and library that have
335 already been installed. Make sure that the compiler (e.g.,
336 <code>g++</code>) is in your <code>PATH</code>. If you are
337 using shared libraries, then you must also ensure that the
338 directory containing the shared version of libstdc++ is in your
339 <code>LD_LIBRARY_PATH</code>, or equivalent. If your GCC source
340 tree is at <code>/path/to/gcc</code>, then you can run the tests
345 runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
349 The testsuite will create a number of files in the directory in
350 which you run this command,. Some of those files might use the
351 same name as files created by other testsuites (like the ones
352 for GCC and G++), so you should not try to run all the
353 testsuites in parallel from the same directory.
357 In addition, there are some testing options that are mostly of
358 interest to library maintainers and system integrators. As such,
359 these tests may not work on all cpu and host combinations, and
360 may need to be executed in the
361 <emphasis>libbuilddir/testsuite</emphasis> directory. These
362 options include, but are not necessarily limited to, the
371 Five files are generated that determine what test files
372 are run. These files are:
378 <emphasis>testsuite_files</emphasis>
381 This is a list of all the test cases that will be run. Each
382 test case is on a separate line, given with an absolute path
383 from the <emphasis>libsrcdir/testsuite</emphasis> directory.
389 <emphasis>testsuite_files_interactive</emphasis>
392 This is a list of all the interactive test cases, using the
393 same format as the file list above. These tests are not run
400 <emphasis>testsuite_files_performance</emphasis>
403 This is a list of all the performance test cases, using the
404 same format as the file list above. These tests are not run
411 <emphasis>testsuite_thread</emphasis>
414 This file indicates that the host system can run tests which
415 involved multiple threads.
421 <emphasis>testsuite_wchar_t</emphasis>
424 This file indicates that the host system can run the wchar_t
425 tests, and corresponds to the macro definition <code>
426 _GLIBCXX_USE_WCHAR_T</code> in the file c++config.h.
436 The library ABI can be tested. This involves testing the shared
437 library against an ABI-defining previous version of symbol
446 This rule compiles, but does not link or execute, the
447 <emphasis>testsuite_files</emphasis> test cases and displays the
452 make check-performance
456 This rule runs through the
457 <emphasis>testsuite_files_performance</emphasis> test cases and
458 collects information for performance analysis and can be used to
459 spot performance regressions. Various timing information is
460 collected, as well as number of hard page faults, and memory
461 used. This is not run by default, and the implementation is in
466 We are interested in any strange failures of the testsuite;
467 please email the main libstdc++ mailing list if you see
468 something odd or have questions.
472 <section xml:id="test.run.permutations"><info><title>Permutations</title></info>
475 To run the libstdc++ test suite under the <link linkend="manual.ext.debug_mode">debug mode</link>, edit
476 <filename>libstdc++-v3/scripts/testsuite_flags</filename> to add the
477 compile-time flag <constant>-D_GLIBCXX_DEBUG</constant> to the
478 result printed by the <literal>--build-cxx</literal>
479 option. Additionally, add the
480 <constant>-D_GLIBCXX_DEBUG_PEDANTIC</constant> flag to turn on
481 pedantic checking. The libstdc++ test suite should produce
482 precisely the same results under debug mode that it does under
483 release mode: any deviation indicates an error in either the
484 library or the test suite.
488 The <link linkend="manual.ext.parallel_mode">parallel
489 mode</link> can be tested in much the same manner, substituting
490 <constant>-D_GLIBCXX_PARALLEL</constant> for
491 <constant>-D_GLIBCXX_DEBUG</constant> in the previous paragraph.
495 Or, just run the testsuites with <constant>CXXFLAGS</constant>
496 set to <constant>-D_GLIBCXX_DEBUG</constant> or
497 <constant>-D_GLIBCXX_PARALLEL</constant>.
502 <section xml:id="test.new_tests"><info><title>Writing a new test case</title></info>
506 The first step in making a new test case is to choose the correct
507 directory and file name, given the organization as previously
512 All files are copyright the FSF, and GPL'd: this is very
513 important. The first copyright year should correspond to the date
514 the file was checked in to SVN.
518 As per the dejagnu instructions, always return 0 from main to
523 A bunch of utility functions and classes have already been
524 abstracted out into the testsuite utility library, <code>
525 libtestc++</code>. To use this functionality, just include the
526 appropriate header file: the library or specific object files will
527 automatically be linked in as part of the testsuite run.
531 For a test that needs to take advantage of the dejagnu test
532 harness, what follows below is a list of special keyword that
533 harness uses. Basically, a test case contains dg-keywords (see
534 dg.exp) indicating what to do and what kinds of behavior are to be
535 expected. New test cases should be written with the new style
536 DejaGnu framework in mind.
540 To ease transition, here is the list of dg-keyword documentation
545 # The currently supported options are:
550 # dg-options "options ..." [{ target selector }]
551 # specify special options to pass to the tool (eg: compiler)
553 # dg-do do-what-keyword [{ target/xfail selector }]
554 # `do-what-keyword' is tool specific and is passed unchanged to
555 # ${tool}-dg-test. An example is gcc where `keyword' can be any of:
556 # preprocess|compile|assemble|link|run
557 # and will do one of: produce a .i, produce a .s, produce a .o,
558 # produce an a.out, or produce an a.out and run it (the default is
561 # dg-error regexp comment [{ target/xfail selector } [{.|0|linenum}]]
562 # indicate an error message <regexp> is expected on this line
563 # (the test fails if it doesn't occur)
564 # Linenum=0 for general tool messages (eg: -V arg missing).
565 # "." means the current line.
567 # dg-warning regexp comment [{ target/xfail selector } [{.|0|linenum}]]
568 # indicate a warning message <regexp> is expected on this line
569 # (the test fails if it doesn't occur)
571 # dg-bogus regexp comment [{ target/xfail selector } [{.|0|linenum}]]
572 # indicate a bogus error message <regexp> use to occur here
573 # (the test fails if it does occur)
575 # dg-build regexp comment [{ target/xfail selector }]
576 # indicate the build use to fail for some reason
577 # (errors covered here include bad assembler generated, tool crashes,
579 # (the test fails if it does occur)
581 # dg-excess-errors comment [{ target/xfail selector }]
582 # indicate excess errors are expected (any line)
583 # (this should only be used sparingly and temporarily)
585 # dg-output regexp [{ target selector }]
586 # indicate the expected output of the program is <regexp>
587 # (there may be multiple occurrences of this, they are concatenated)
589 # dg-final { tcl code }
590 # add some tcl code to be run at the end
591 # (there may be multiple occurrences of this, they are concatenated)
592 # (unbalanced braces must be \-escaped)
594 # "{ target selector }" is a list of expressions that determine whether the
595 # test succeeds or fails for a particular target, or in some cases whether the
596 # option applies for a particular target. If the case of `dg-do' it specifies
597 # whether the test case is even attempted on the specified target.
599 # The target selector is always optional. The format is one of:
601 # { xfail *-*-* ... } - the test is expected to fail for the given targets
602 # { target *-*-* ... } - the option only applies to the given targets
604 # At least one target must be specified, use *-*-* for "all targets".
605 # At present it is not possible to specify both `xfail' and `target'.
606 # "native" may be used in place of "*-*-*".
608 Example 1: Testing compilation only
611 Example 2: Testing for expected warnings on line 36, which all targets fail
612 // { dg-warning "string literals" "" { xfail *-*-* } 36 }
614 Example 3: Testing for expected warnings on line 36
615 // { dg-warning "string literals" "" { target *-*-* } 36 }
617 Example 4: Testing for compilation errors on line 41
619 // { dg-error "no match for" "" { target *-*-* } 41 }
621 Example 5: Testing with special command line settings, or without the
622 use of pre-compiled headers, in particular the stdc++.h.gch file. Any
623 options here will override the DEFAULT_CXXFLAGS and PCH_CXXFLAGS set
624 up in the normal.exp file.
625 // { dg-options "-O0" { target *-*-* } }
629 More examples can be found in the libstdc++-v3/testsuite/*/*.cc files.
634 <section xml:id="test.harness" xreflabel="Test Harness and Utilities"><info><title>Test Harness and Utilities</title></info>
637 <section xml:id="test.harness.dejagnu"><info><title>Dejagnu Harness Details</title></info>
640 Underlying details of testing for conformance and regressions are
641 abstracted via the GNU Dejagnu package. This is similar to the
646 <para>This is information for those looking at making changes to the testsuite
647 structure, and/or needing to trace dejagnu's actions with --verbose. This
648 will not be useful to people who are "merely" adding new tests to the existing
652 <para>The first key point when working with dejagnu is the idea of a "tool".
653 Files, directories, and functions are all implicitly used when they are
654 named after the tool in use. Here, the tool will always be "libstdc++".
657 <para>The <code>lib</code> subdir contains support routines. The
658 <code>lib/libstdc++.exp</code> file ("support library") is loaded
659 automagically, and must explicitly load the others. For example, files can
660 be copied from the core compiler's support directory into <code>lib</code>.
663 <para>Some routines in <code>lib/libstdc++.exp</code> are callbacks, some are
664 our own. Callbacks must be prefixed with the name of the tool. To easily
665 distinguish the others, by convention our own routines are named "v3-*".
668 <para>The next key point when working with dejagnu is "test files". Any
669 directory whose name starts with the tool name will be searched for test files.
670 (We have only one.) In those directories, any <code>.exp</code> file is
671 considered a test file, and will be run in turn. Our main test file is called
672 <code>normal.exp</code>; it runs all the tests in testsuite_files using the
673 callbacks loaded from the support library.
676 <para>The <code>config</code> directory is searched for any particular "target
677 board" information unique to this library. This is currently unused and sets
678 only default variables.
683 <section xml:id="test.harness.utils"><info><title>Utilities</title></info>
688 The testsuite directory also contains some files that implement
689 functionality that is intended to make writing test cases easier,
690 or to avoid duplication, or to provide error checking in a way that
691 is consistent across platforms and test harnesses. A stand-alone
692 executable, called <emphasis>abi_check</emphasis>, and a static
693 library called <emphasis>libtestc++</emphasis> are
694 constructed. Both of these items are not installed, and only used
699 These files include the following functionality:
705 <emphasis>testsuite_abi.h</emphasis>,
706 <emphasis>testsuite_abi.cc</emphasis>,
707 <emphasis>testsuite_abi_check.cc</emphasis>
710 Creates the executable <emphasis>abi_check</emphasis>.
711 Used to check correctness of symbol versioning, visibility of
712 exported symbols, and compatibility on symbols in the shared
713 library, for hosts that support this feature. More information
714 can be found in the ABI documentation <link linkend="appendix.porting.abi">here</link>
719 <emphasis>testsuite_allocator.h</emphasis>,
720 <emphasis>testsuite_allocator.cc</emphasis>
723 Contains specialized allocators that keep track of construction
724 and destruction. Also, support for overriding global new and
725 delete operators, including verification that new and delete
726 are called during execution, and that allocation over max_size
732 <emphasis>testsuite_character.h</emphasis>
735 Contains <code>std::char_traits</code> and
736 <code>std::codecvt</code> specializations for a user-defined
742 <emphasis>testsuite_hooks.h</emphasis>,
743 <emphasis>testsuite_hooks.cc</emphasis>
746 A large number of utilities, including:
749 <listitem><para>VERIFY</para></listitem>
750 <listitem><para>set_memory_limits</para></listitem>
751 <listitem><para>verify_demangle</para></listitem>
752 <listitem><para>run_tests_wrapped_locale</para></listitem>
753 <listitem><para>run_tests_wrapped_env</para></listitem>
754 <listitem><para>try_named_locale</para></listitem>
755 <listitem><para>try_mkfifo</para></listitem>
756 <listitem><para>func_callback</para></listitem>
757 <listitem><para>counter</para></listitem>
758 <listitem><para>copy_tracker</para></listitem>
759 <listitem><para>copy_constructor</para></listitem>
760 <listitem><para>assignment_operator</para></listitem>
761 <listitem><para>destructor</para></listitem>
763 <para>pod_char, pod_int and associated char_traits specializations</para>
769 <emphasis>testsuite_io.h</emphasis>
772 Error, exception, and constraint checking for
773 <code>std::streambuf, std::basic_stringbuf, std::basic_filebuf</code>.
778 <emphasis>testsuite_iterators.h</emphasis>
781 Wrappers for various iterators.
786 <emphasis>testsuite_performance.h</emphasis>
789 A number of class abstractions for performance counters, and
790 reporting functions including:
793 <listitem><para>time_counter</para></listitem>
794 <listitem><para>resource_counter</para></listitem>
795 <listitem><para>report_performance</para></listitem>
803 <section xml:id="test.special"><info><title>Special Topics</title></info>
806 <section xml:id="test.exception.safety"><info><title>
807 Qualifying Exception Safety Guarantees
809 <primary>Test</primary>
810 <secondary>Exception Safety</secondary>
815 <section xml:id="test.exception.safety.overview"><info><title>Overview</title></info>
819 Testing is composed of running a particular test sequence,
820 and looking at what happens to the surrounding code when
821 exceptions are thrown. Each test is composed of measuring
822 initial state, executing a particular sequence of code under
823 some instrumented conditions, measuring a final state, and
824 then examining the differences between the two states.
828 Test sequences are composed of constructed code sequences
829 that exercise a particular function or member function, and
830 either confirm no exceptions were generated, or confirm the
831 consistency/coherency of the test subject in the event of a
836 Random code paths can be constructed using the basic test
837 sequences and instrumentation as above, only combined in a
838 random or pseudo-random way.
841 <para> To compute the code paths that throw, test instruments
842 are used that throw on allocation events
843 (<classname>__gnu_cxx::throw_allocator_random</classname>
844 and <classname>__gnu_cxx::throw_allocator_limit</classname>)
845 and copy, assignment, comparison, increment, swap, and
847 (<classname>__gnu_cxx::throw_type_random</classname>
848 and <classname>__gnu_cxx::throw_type_limit</classname>). Looping
849 through a given test sequence and conditionally throwing in
850 all instrumented places. Then, when the test sequence
851 completes without an exception being thrown, assume all
852 potential error paths have been exercised in a sequential
858 <section xml:id="test.exception.safety.status"><info><title>
870 <filename>testsuite/23_containers/list/modifiers/3.cc</filename>.
876 Policy Based Data Structures
879 For example, take the test
880 functor <classname>rand_reg_test</classname> in
881 in <filename>testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc</filename>. This uses <classname>container_rand_regression_test</classname> in
882 <filename>testsuite/util/regression/rand/assoc/container_rand_regression_test.h</filename>.
887 Which has several tests for container member functions,
888 Includes control and test container objects. Configuration includes
889 random seed, iterations, number of distinct values, and the
890 probability that an exception will be thrown. Assumes instantiating
891 container uses an extension
892 allocator, <classname>__gnu_cxx::throw_allocator_random</classname>,
893 as the allocator type.
899 C++11 Container Requirements.
903 Coverage is currently limited to testing container
904 requirements for exception safety,
905 although <classname>__gnu_cxx::throw_type</classname> meets
906 the additional type requirements for testing numeric data
907 structures and instantiating algorithms.
911 Of particular interest is extending testing to algorithms and
912 then to parallel algorithms. Also io and locales.
916 The test instrumentation should also be extended to add
917 instrumentation to <classname>iterator</classname>
918 and <classname>const_iterator</classname> types that throw
919 conditionally on iterator operations.
926 <section xml:id="test.exception.safety.containers"><info><title>
927 C++11 Requirements Test Sequence Descriptions
938 Basic consistency on exception propagation tests. For
939 each container, an object of that container is constructed,
940 a specific member function is exercised in
941 a <literal>try</literal> block, and then any thrown
942 exceptions lead to error checking in the appropriate
943 <literal>catch</literal> block. The container's use of
944 resources is compared to the container's use prior to the
945 test block. Resource monitoring is limited to allocations
946 made through the container's <type>allocator_type</type>,
947 which should be sufficient for container data
948 structures. Included in these tests are member functions
949 are <type>iterator</type> and <type>const_iterator</type>
950 operations, <function>pop_front</function>, <function>pop_back</function>, <function>push_front</function>, <function>push_back</function>, <function>insert</function>, <function>erase</function>, <function>swap</function>, <function>clear</function>,
951 and <function>rehash</function>. The container in question is
952 instantiated with two instrumented template arguments,
953 with <classname>__gnu_cxx::throw_allocator_limit</classname>
954 as the allocator type, and
955 with <classname>__gnu_cxx::throw_type_limit</classname> as
956 the value type. This allows the test to loop through
957 conditional throw points.
961 The general form is demonstrated in
962 <filename>testsuite/23_containers/list/requirements/exception/basic.cc
963 </filename>. The instantiating test object is <classname>__gnu_test::basic_safety</classname> and is detailed in <filename>testsuite/util/exception/safety.h</filename>.
970 Generation Prohibited
974 Exception generation tests. For each container, an object of
975 that container is constructed and all member functions
976 required to not throw exceptions are exercised. Included in
977 these tests are member functions
978 are <type>iterator</type> and <type>const_iterator</type> operations, <function>erase</function>, <function>pop_front</function>, <function>pop_back</function>, <function>swap</function>,
979 and <function>clear</function>. The container in question is
980 instantiated with two instrumented template arguments,
981 with <classname>__gnu_cxx::throw_allocator_random</classname>
982 as the allocator type, and
983 with <classname>__gnu_cxx::throw_type_random</classname> as
984 the value type. This test does not loop, an instead is sudden
985 death: first error fails.
988 The general form is demonstrated in
989 <filename>testsuite/23_containers/list/requirements/exception/generation_prohibited.cc
990 </filename>. The instantiating test object is <classname>__gnu_test::generation_prohibited</classname> and is detailed in <filename>testsuite/util/exception/safety.h</filename>.
997 Propagation Consistent
1001 Container rollback on exception propagation tests. For
1002 each container, an object of that container is constructed,
1003 a specific member function that requires rollback to a previous
1004 known good state is exercised in
1005 a <literal>try</literal> block, and then any thrown
1006 exceptions lead to error checking in the appropriate
1007 <literal>catch</literal> block. The container is compared to
1008 the container's last known good state using such parameters
1009 as size, contents, and iterator references. Included in these
1010 tests are member functions
1011 are <function>push_front</function>, <function>push_back</function>, <function>insert</function>,
1012 and <function>rehash</function>. The container in question is
1013 instantiated with two instrumented template arguments,
1014 with <classname>__gnu_cxx::throw_allocator_limit</classname>
1015 as the allocator type, and
1016 with <classname>__gnu_cxx::throw_type_limit</classname> as
1017 the value type. This allows the test to loop through
1018 conditional throw points.
1022 The general form demonstrated in
1023 <filename>testsuite/23_containers/list/requirements/exception/propagation_coherent.cc
1024 </filename>. The instantiating test object is <classname>__gnu_test::propagation_coherent</classname> and is detailed in <filename>testsuite/util/exception/safety.h</filename>.