1 <sect1 id=
"manual.intro.setup.test" xreflabel=
"Testing">
2 <?dbhtml filename=
"test.html"?>
33 The libstdc++ testsuite includes testing for standard conformance,
34 regressions, ABI, and performance.
37 <sect2 id=
"test.organization" xreflabel=
"Test Organization">
38 <title>Organization
</title>
40 <sect3 id=
"test.organization.layout" xreflabel=
"Directory Layout">
41 <title>Directory Layout
</title>
44 The directory
<emphasis>libsrcdir/testsuite
</emphasis> contains the
45 individual test cases organized in sub-directories corresponding to
46 chapters of the C++ standard (detailed below), the dejagnu test
47 harness support files, and sources to various testsuite utilities
48 that are packaged in a separate testing library.
52 All test cases for functionality required by the runtime components
53 of the C++ standard (ISO
14882) are files within the following
74 In addition, the following directories include test files:
78 tr1 Tests for components as described by the Technical Report on Standard Library Extensions (TR1).
79 backward Tests for backwards compatibility and deprecated features.
80 demangle Tests for __cxa_demangle, the IA
64 C++ ABI demangler
81 ext Tests for extensions.
82 performance Tests for performance analysis, and performance regressions.
86 Some directories don't have test files, but instead contain
87 auxiliary information:
91 config Files for the dejagnu test harness.
92 lib Files for the dejagnu test harness.
93 libstdc++* Files for the dejagnu test harness.
94 data Sample text files for testing input and output.
95 util Files for libtestc++, utilities and testing routines.
99 Within a directory that includes test files, there may be
100 additional subdirectories, or files. Originally, test cases
101 were appended to one file that represented a particular section
102 of the chapter under test, and was named accordingly. For
103 instance, to test items related to
<code> 21.3.6.1 -
104 basic_string::find [lib.string::find]
</code> in the standard,
105 the following was used:
111 However, that practice soon became a liability as the test cases
112 became huge and unwieldy, and testing new or extended
113 functionality (like wide characters or named locales) became
114 frustrating, leading to aggressive pruning of test cases on some
115 platforms that covered up implementation errors. Now, the test
116 suite has a policy of one file, one test case, which solves the
117 above issues and gives finer grained results and more manageable
118 error debugging. As an example, the test case quoted above
122 21_strings/basic_string/find/char/
1.cc
123 21_strings/basic_string/find/char/
2.cc
124 21_strings/basic_string/find/char/
3.cc
125 21_strings/basic_string/find/wchar_t/
1.cc
126 21_strings/basic_string/find/wchar_t/
2.cc
127 21_strings/basic_string/find/wchar_t/
3.cc
131 All new tests should be written with the policy of one test
132 case, one file in mind.
137 <sect3 id=
"test.organization.naming" xreflabel=
"Naming Conventions">
138 <title>Naming Conventions
</title>
141 In addition, there are some special names and suffixes that are
142 used within the testsuite to designate particular kinds of
149 <emphasis>_xin.cc
</emphasis>
152 This test case expects some kind of interactive input in order
153 to finish or pass. At the moment, the interactive tests are not
154 run by default. Instead, they are run by hand, like:
157 g++
27_io/objects/char/
3_xin.cc
158 cat
27_io/objects/char/
3_xin.in | a.out
163 <emphasis>.in
</emphasis>
166 This file contains the expected input for the corresponding
<emphasis>
167 _xin.cc
</emphasis> test case.
172 <emphasis>_neg.cc
</emphasis>
175 This test case is expected to fail: it's a negative test. At the
176 moment, these are almost always compile time errors.
181 <emphasis>char
</emphasis>
184 This can either be a directory name or part of a longer file
185 name, and indicates that this file, or the files within this
186 directory are testing the
<code>char
</code> instantiation of a
192 <emphasis>wchar_t
</emphasis>
195 This can either be a directory name or part of a longer file
196 name, and indicates that this file, or the files within this
197 directory are testing the
<code>wchar_t
</code> instantiation of
198 a template. Some hosts do not support
<code>wchar_t
</code>
199 functionality, so for these targets, all of these tests will not
205 <emphasis>thread
</emphasis>
208 This can either be a directory name or part of a longer file
209 name, and indicates that this file, or the files within this
210 directory are testing situations where multiple threads are
216 <emphasis>performance
</emphasis>
219 This can either be an enclosing directory name or part of a
220 specific file name. This indicates a test that is used to
221 analyze runtime performance, for performance regression testing,
222 or for other optimization related analysis. At the moment, these
223 test cases are not run by default.
232 <sect2 id=
"test.run" xreflabel=
"Running the Testsuite">
233 <title>Running the Testsuite
</title>
235 <sect3 id=
"test.run.basic">
239 You can check the status of the build without installing it
240 using the dejagnu harness, much like the rest of the gcc
242 <programlisting> make check
</programlisting>
243 <para>in the
<emphasis>libbuilddir
</emphasis> directory.
</para>
245 <programlisting> make check-target-libstdc++-v3
</programlisting>
246 <para>in the
<emphasis>gccbuilddir
</emphasis> directory.
250 These commands are functionally equivalent and will create a
251 'testsuite' directory underneath
252 <emphasis>libbuilddir
</emphasis> containing the results of the
253 tests. Two results files will be generated:
<emphasis>
254 libstdc++.sum
</emphasis>, which is a PASS/FAIL summary for each
255 test, and
<emphasis>libstdc++.log
</emphasis> which is a log of
256 the exact command line passed to the compiler, the compiler
257 output, and the executable output (if any).
261 Archives of test results for various versions and platforms are
262 available on the GCC website in the
<ulink
263 url=
"http://gcc.gnu.org/gcc-4.3/buildstat.html">build
264 status
</ulink> section of each individual release, and are also
265 archived on a daily basis on the
<ulink
266 url=
"http://gcc.gnu.org/ml/gcc-testresults/current">gcc-testresults
</ulink>
267 mailing list. Please check either of these places for a similar
268 combination of source version, operating system, and host CPU.
272 <sect3 id=
"test.run.variations">
273 <title>Variations
</title>
275 There are several options for running tests, including testing
276 the regression tests, testing a subset of the regression tests,
277 testing the performance tests, testing just compilation, testing
278 installed tools, etc. In addition, there is a special rule for
279 checking the exported symbols of the shared library.
282 To debug the dejagnu test harness during runs, try invoking with a
283 specific argument to the variable RUNTESTFLAGS, as below.
287 make check-target-libstdc++-v3
RUNTESTFLAGS=
"-v"
295 make check-target-libstdc++-v3
RUNTESTFLAGS=
"-v -v"
299 To run a subset of the library tests, you will need to generate
300 the
<emphasis>testsuite_files
</emphasis> file by running
301 <command>make testsuite_files
</command> in the
302 <emphasis>libbuilddir/testsuite
</emphasis> directory, described
303 below. Edit the file to remove the tests you don't want and
304 then run the testsuite as normal.
308 There are two ways to run on a simulator: set up DEJAGNU to point to a
309 specially crafted site.exp, or pass down --target_board flags.
313 Example flags to pass down for various embedded builds are as follows:
317 --target=powerpc-eabism (libgloss/sim)
318 make check-target-libstdc++-v3
RUNTESTFLAGS=
"--target_board=powerpc-sim"
320 --target=calmrisc32 (libgloss/sid)
321 make check-target-libstdc++-v3
RUNTESTFLAGS=
"--target_board=calmrisc32-sid"
323 --target=xscale-elf (newlib/sim)
324 make check-target-libstdc++-v3
RUNTESTFLAGS=
"--target_board=arm-sim"
328 Also, here is an example of how to run the libstdc++ testsuite
329 for a multilibed build directory with different ABI settings:
333 make check-target-libstdc++-v3 RUNTESTFLAGS='--target_board \
"unix{-mabi=32,,-mabi=64}\"'
337 You can run the tests with a compiler and library that have
338 already been installed. Make sure that the compiler (e.g.,
339 <code>g++
</code>) is in your
<code>PATH
</code>. If you are
340 using shared libraries, then you must also ensure that the
341 directory containing the shared version of libstdc++ is in your
342 <code>LD_LIBRARY_PATH
</code>, or equivalent. If your GCC source
343 tree is at
<code>/path/to/gcc
</code>, then you can run the tests
348 runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
352 The testsuite will create a number of files in the directory in
353 which you run this command,. Some of those files might use the
354 same name as files created by other testsuites (like the ones
355 for GCC and G++), so you should not try to run all the
356 testsuites in parallel from the same directory.
360 In addition, there are some testing options that are mostly of
361 interest to library maintainers and system integrators. As such,
362 these tests may not work on all cpu and host combinations, and
363 may need to be executed in the
364 <emphasis>libbuilddir/testsuite
</emphasis> directory. These
365 options include, but are not necessarily limited to, the
374 Five files are generated that determine what test files
375 are run. These files are:
381 <emphasis>testsuite_files
</emphasis>
384 This is a list of all the test cases that will be run. Each
385 test case is on a separate line, given with an absolute path
386 from the
<emphasis>libsrcdir/testsuite
</emphasis> directory.
392 <emphasis>testsuite_files_interactive
</emphasis>
395 This is a list of all the interactive test cases, using the
396 same format as the file list above. These tests are not run
403 <emphasis>testsuite_files_performance
</emphasis>
406 This is a list of all the performance test cases, using the
407 same format as the file list above. These tests are not run
414 <emphasis>testsuite_thread
</emphasis>
417 This file indicates that the host system can run tests which
418 involved multiple threads.
424 <emphasis>testsuite_wchar_t
</emphasis>
427 This file indicates that the host system can run the wchar_t
428 tests, and corresponds to the macro definition
<code>
429 _GLIBCXX_USE_WCHAR_T
</code> in the file c++config.h.
439 The library ABI can be tested. This involves testing the shared
440 library against an ABI-defining previous version of symbol
449 This rule compiles, but does not link or execute, the
450 <emphasis>testsuite_files
</emphasis> test cases and displays the
455 make check-performance
459 This rule runs through the
460 <emphasis>testsuite_files_performance
</emphasis> test cases and
461 collects information for performance analysis and can be used to
462 spot performance regressions. Various timing information is
463 collected, as well as number of hard page faults, and memory
464 used. This is not run by default, and the implementation is in
469 We are interested in any strange failures of the testsuite;
470 please email the main libstdc++ mailing list if you see
471 something odd or have questions.
475 <sect3 id=
"test.run.permutations">
476 <title>Permutations
</title>
478 To run the libstdc++ test suite under the
<link
479 linkend=
"manual.ext.debug_mode">debug mode
</link>, edit
480 <filename>libstdc++-v3/scripts/testsuite_flags
</filename> to add the
481 compile-time flag
<constant>-D_GLIBCXX_DEBUG
</constant> to the
482 result printed by the
<literal>--build-cxx
</literal>
483 option. Additionally, add the
484 <constant>-D_GLIBCXX_DEBUG_PEDANTIC
</constant> flag to turn on
485 pedantic checking. The libstdc++ test suite should produce
486 precisely the same results under debug mode that it does under
487 release mode: any deviation indicates an error in either the
488 library or the test suite.
492 The
<link linkend=
"manual.ext.parallel_mode">parallel
493 mode
</link> can be tested in much the same manner, substituting
494 <constant>-D_GLIBCXX_PARALLEL
</constant> for
495 <constant>-D_GLIBCXX_DEBUG
</constant> in the previous paragraph.
499 Or, just run the testsuites with
<constant>CXXFLAGS
</constant>
500 set to
<constant>-D_GLIBCXX_DEBUG
</constant> or
501 <constant>-D_GLIBCXX_PARALLEL
</constant>.
506 <sect2 id=
"test.new_tests">
507 <title>Writing a new test case
</title>
510 The first step in making a new test case is to choose the correct
511 directory and file name, given the organization as previously
516 All files are copyright the FSF, and GPL'd: this is very
517 important. The first copyright year should correspond to the date
518 the file was checked in to SVN.
522 As per the dejagnu instructions, always return
0 from main to
527 A bunch of utility functions and classes have already been
528 abstracted out into the testsuite utility library,
<code>
529 libtestc++
</code>. To use this functionality, just include the
530 appropriate header file: the library or specific object files will
531 automatically be linked in as part of the testsuite run.
535 For a test that needs to take advantage of the dejagnu test
536 harness, what follows below is a list of special keyword that
537 harness uses. Basically, a test case contains dg-keywords (see
538 dg.exp) indicating what to do and what kinds of behavior are to be
539 expected. New test cases should be written with the new style
540 DejaGnu framework in mind.
544 To ease transition, here is the list of dg-keyword documentation
549 # The currently supported options are:
554 # dg-options
"options ..." [{ target selector }]
555 # specify special options to pass to the tool (eg: compiler)
557 # dg-do do-what-keyword [{ target/xfail selector }]
558 # `do-what-keyword' is tool specific and is passed unchanged to
559 # ${tool}-dg-test. An example is gcc where `keyword' can be any of:
560 # preprocess|compile|assemble|link|run
561 # and will do one of: produce a .i, produce a .s, produce a .o,
562 # produce an a.out, or produce an a.out and run it (the default is
565 # dg-error regexp comment [{ target/xfail selector } [{.|
0|linenum}]]
566 # indicate an error message
<regexp
> is expected on this line
567 # (the test fails if it doesn't occur)
568 # Linenum=
0 for general tool messages (eg: -V arg missing).
569 #
"." means the current line.
571 # dg-warning regexp comment [{ target/xfail selector } [{.|
0|linenum}]]
572 # indicate a warning message
<regexp
> is expected on this line
573 # (the test fails if it doesn't occur)
575 # dg-bogus regexp comment [{ target/xfail selector } [{.|
0|linenum}]]
576 # indicate a bogus error message
<regexp
> use to occur here
577 # (the test fails if it does occur)
579 # dg-build regexp comment [{ target/xfail selector }]
580 # indicate the build use to fail for some reason
581 # (errors covered here include bad assembler generated, tool crashes,
583 # (the test fails if it does occur)
585 # dg-excess-errors comment [{ target/xfail selector }]
586 # indicate excess errors are expected (any line)
587 # (this should only be used sparingly and temporarily)
589 # dg-output regexp [{ target selector }]
590 # indicate the expected output of the program is
<regexp
>
591 # (there may be multiple occurrences of this, they are concatenated)
593 # dg-final { tcl code }
594 # add some tcl code to be run at the end
595 # (there may be multiple occurrences of this, they are concatenated)
596 # (unbalanced braces must be \-escaped)
598 #
"{ target selector }" is a list of expressions that determine whether the
599 # test succeeds or fails for a particular target, or in some cases whether the
600 # option applies for a particular target. If the case of `dg-do' it specifies
601 # whether the test case is even attempted on the specified target.
603 # The target selector is always optional. The format is one of:
605 # { xfail *-*-* ... } - the test is expected to fail for the given targets
606 # { target *-*-* ... } - the option only applies to the given targets
608 # At least one target must be specified, use *-*-* for
"all targets".
609 # At present it is not possible to specify both `xfail' and `target'.
610 #
"native" may be used in place of
"*-*-*".
612 Example
1: Testing compilation only
615 Example
2: Testing for expected warnings on line
36, which all targets fail
616 // { dg-warning
"string literals" "" { xfail *-*-* }
36
618 Example
3: Testing for expected warnings on line
36
619 // { dg-warning
"string literals" "" { target *-*-* }
36
621 Example
4: Testing for compilation errors on line
41
623 // { dg-error
"no match for" "" { target *-*-* }
41 }
625 Example
5: Testing with special command line settings, or without the
626 use of pre-compiled headers, in particular the stdc++.h.gch file. Any
627 options here will override the DEFAULT_CXXFLAGS and PCH_CXXFLAGS set
628 up in the normal.exp file.
629 // { dg-options
"-O0" { target *-*-* } }
633 More examples can be found in the libstdc++-v3/testsuite/*/*.cc files.
638 <sect2 id=
"test.harness" xreflabel=
"Test Harness and Utilities">
639 <title>Test Harness and Utilities
</title>
641 <sect3 id=
"test.harness.dejagnu">
642 <title>Dejagnu Harness Details
</title>
644 Underlying details of testing for conformance and regressions are
645 abstracted via the GNU Dejagnu package. This is similar to the
650 <para>This is information for those looking at making changes to the testsuite
651 structure, and/or needing to trace dejagnu's actions with --verbose. This
652 will not be useful to people who are
"merely" adding new tests to the existing
656 <para>The first key point when working with dejagnu is the idea of a
"tool".
657 Files, directories, and functions are all implicitly used when they are
658 named after the tool in use. Here, the tool will always be
"libstdc++".
661 <para>The
<code>lib
</code> subdir contains support routines. The
662 <code>lib/libstdc++.exp
</code> file (
"support library") is loaded
663 automagically, and must explicitly load the others. For example, files can
664 be copied from the core compiler's support directory into
<code>lib
</code>.
667 <para>Some routines in
<code>lib/libstdc++.exp
</code> are callbacks, some are
668 our own. Callbacks must be prefixed with the name of the tool. To easily
669 distinguish the others, by convention our own routines are named
"v3-*".
672 <para>The next key point when working with dejagnu is
"test files". Any
673 directory whose name starts with the tool name will be searched for test files.
674 (We have only one.) In those directories, any
<code>.exp
</code> file is
675 considered a test file, and will be run in turn. Our main test file is called
676 <code>normal.exp
</code>; it runs all the tests in testsuite_files using the
677 callbacks loaded from the support library.
680 <para>The
<code>config
</code> directory is searched for any particular
"target
681 board" information unique to this library. This is currently unused and sets
682 only default variables.
687 <sect3 id=
"test.harness.utils">
688 <title>Utilities
</title>
692 The testsuite directory also contains some files that implement
693 functionality that is intended to make writing test cases easier,
694 or to avoid duplication, or to provide error checking in a way that
695 is consistent across platforms and test harnesses. A stand-alone
696 executable, called
<emphasis>abi_check
</emphasis>, and a static
697 library called
<emphasis>libtestc++
</emphasis> are
698 constructed. Both of these items are not installed, and only used
703 These files include the following functionality:
709 <emphasis>testsuite_abi.h
</emphasis>,
710 <emphasis>testsuite_abi.cc
</emphasis>,
711 <emphasis>testsuite_abi_check.cc
</emphasis>
714 Creates the executable
<emphasis>abi_check
</emphasis>.
715 Used to check correctness of symbol versioning, visibility of
716 exported symbols, and compatibility on symbols in the shared
717 library, for hosts that support this feature. More information
718 can be found in the ABI documentation
<link linkend=
"appendix.porting.abi">here
</link>
723 <emphasis>testsuite_allocator.h
</emphasis>,
724 <emphasis>testsuite_allocator.cc
</emphasis>
727 Contains specialized allocators that keep track of construction
728 and destruction. Also, support for overriding global new and
729 delete operators, including verification that new and delete
730 are called during execution, and that allocation over max_size
736 <emphasis>testsuite_character.h
</emphasis>
739 Contains
<code>std::char_traits
</code> and
740 <code>std::codecvt
</code> specializations for a user-defined
746 <emphasis>testsuite_hooks.h
</emphasis>,
747 <emphasis>testsuite_hooks.cc
</emphasis>
750 A large number of utilities, including:
753 <listitem><para>VERIFY
</para></listitem>
754 <listitem><para>set_memory_limits
</para></listitem>
755 <listitem><para>verify_demangle
</para></listitem>
756 <listitem><para>run_tests_wrapped_locale
</para></listitem>
757 <listitem><para>run_tests_wrapped_env
</para></listitem>
758 <listitem><para>try_named_locale
</para></listitem>
759 <listitem><para>try_mkfifo
</para></listitem>
760 <listitem><para>func_callback
</para></listitem>
761 <listitem><para>counter
</para></listitem>
762 <listitem><para>copy_tracker
</para></listitem>
763 <listitem><para>copy_constructor
</para></listitem>
764 <listitem><para>assignment_operator
</para></listitem>
765 <listitem><para>destructor
</para></listitem>
767 <para>pod_char, pod_int and associated char_traits specializations
</para>
773 <emphasis>testsuite_io.h
</emphasis>
776 Error, exception, and constraint checking for
777 <code>std::streambuf, std::basic_stringbuf, std::basic_filebuf
</code>.
782 <emphasis>testsuite_iterators.h
</emphasis>
785 Wrappers for various iterators.
790 <emphasis>testsuite_performance.h
</emphasis>
793 A number of class abstractions for performance counters, and
794 reporting functions including:
797 <listitem><para>time_counter
</para></listitem>
798 <listitem><para>resource_counter
</para></listitem>
799 <listitem><para>report_performance
</para></listitem>
807 <sect2 id=
"test.special">
808 <title>Special Topics
</title>
810 <sect3 id=
"test.exception.safety">
812 Qualifying Exception Safety Guarantees
814 <primary>Test
</primary>
815 <secondary>Exception Safety
</secondary>
819 <sect4 id=
"test.exception.safety.overview">
820 <title>Overview
</title>
823 Testing is composed of running a particular test sequence,
824 and looking at what happens to the surrounding code when
825 exceptions are thrown. Each test is composed of measuring
826 initial state, executing a particular sequence of code under
827 some instrumented conditions, measuring a final state, and
828 then examining the differences between the two states.
832 Test sequences are composed of constructed code sequences
833 that exercise a particular function or member function, and
834 either confirm no exceptions were generated, or confirm the
835 consistency/coherency of the test subject in the event of a
840 Random code paths can be constructed using the basic test
841 sequences and instrumentation as above, only combined in a
842 random or pseudo-random way.
845 <para> To compute the code paths that throw, test instruments
846 are used that throw on allocation events
847 (
<classname>__gnu_cxx::throw_allocator_random
</classname>
848 and
<classname>__gnu_cxx::throw_allocator_limit
</classname>)
849 and copy, assignment, comparison, increment, swap, and
851 (
<classname>__gnu_cxx::throw_type_random
</classname>
852 and
<classname>__gnu_cxx::throw_type_limit
</classname>). Looping
853 through a given test sequence and conditionally throwing in
854 all instrumented places. Then, when the test sequence
855 completes without an exception being thrown, assume all
856 potential error paths have been exercised in a sequential
862 <sect4 id=
"test.exception.safety.status">
874 <filename>testsuite/
23_containers/list/modifiers/
3.cc
</filename>.
880 Policy Based Data Structures
883 For example, take the test
884 functor
<classname>rand_reg_test
</classname> in
885 in
<filename>testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc
</filename>. This uses
<classname>container_rand_regression_test
</classname> in
886 <filename>testsuite/util/regression/rand/assoc/container_rand_regression_test.h
</filename>.
891 Which has several tests for container member functions,
892 Includes control and test container objects. Configuration includes
893 random seed, iterations, number of distinct values, and the
894 probability that an exception will be thrown. Assumes instantiating
895 container uses an extension
896 allocator,
<classname>__gnu_cxx::throw_allocator_random
</classname>,
897 as the allocator type.
903 C++
0x Container Requirements.
907 Coverage is currently limited to testing container
908 requirements for exception safety,
909 although
<classname>__gnu_cxx::throw_type
</classname> meets
910 the additional type requirements for testing numeric data
911 structures and instantiating algorithms.
915 Of particular interest is extending testing to algorithms and
916 then to parallel algorithms. Also io and locales.
920 The test instrumentation should also be extended to add
921 instrumentation to
<classname>iterator
</classname>
922 and
<classname>const_iterator
</classname> types that throw
923 conditionally on iterator operations.
930 <sect4 id=
"test.exception.safety.containers">
932 C++
0x Requirements Test Sequence Descriptions
942 Basic consistency on exception propagation tests. For
943 each container, an object of that container is constructed,
944 a specific member function is exercised in
945 a
<literal>try
</literal> block, and then any thrown
946 exceptions lead to error checking in the appropriate
947 <literal>catch
</literal> block. The container's use of
948 resources is compared to the container's use prior to the
949 test block. Resource monitoring is limited to allocations
950 made through the container's
<type>allocator_type
</type>,
951 which should be sufficient for container data
952 structures. Included in these tests are member functions
953 are
<type>iterator
</type> and
<type>const_iterator
</type>
954 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>,
955 and
<function>rehash
</function>. The container in question is
956 instantiated with two instrumented template arguments,
957 with
<classname>__gnu_cxx::throw_allocator_limit
</classname>
958 as the allocator type, and
959 with
<classname>__gnu_cxx::throw_type_limit
</classname> as
960 the value type. This allows the test to loop through
961 conditional throw points.
965 The general form is demonstrated in
966 <filename>testsuite/
23_containers/list/requirements/exception/basic.cc
967 </filename>. The instantiating test object is
<classname>__gnu_test::basic_safety
</classname> and is detailed in
<filename>testsuite/util/exception/safety.h
</filename>.
974 Generation Prohibited
978 Exception generation tests. For each container, an object of
979 that container is constructed and all member functions
980 required to not throw exceptions are exercised. Included in
981 these tests are member functions
982 are
<type>iterator
</type> and
<type>const_iterator
</type> operations,
<function>erase
</function>,
<function>pop_front
</function>,
<function>pop_back
</function>,
<function>swap
</function>,
983 and
<function>clear
</function>. The container in question is
984 instantiated with two instrumented template arguments,
985 with
<classname>__gnu_cxx::throw_allocator_random
</classname>
986 as the allocator type, and
987 with
<classname>__gnu_cxx::throw_type_random
</classname> as
988 the value type. This test does not loop, an instead is sudden
989 death: first error fails.
992 The general form is demonstrated in
993 <filename>testsuite/
23_containers/list/requirements/exception/generation_prohibited.cc
994 </filename>. The instantiating test object is
<classname>__gnu_test::generation_prohibited
</classname> and is detailed in
<filename>testsuite/util/exception/safety.h
</filename>.
1001 Propagation Consistent
1005 Container rollback on exception propagation tests. For
1006 each container, an object of that container is constructed,
1007 a specific member function that requires rollback to a previous
1008 known good state is exercised in
1009 a
<literal>try
</literal> block, and then any thrown
1010 exceptions lead to error checking in the appropriate
1011 <literal>catch
</literal> block. The container is compared to
1012 the container's last known good state using such parameters
1013 as size, contents, and iterator references. Included in these
1014 tests are member functions
1015 are
<function>push_front
</function>,
<function>push_back
</function>,
<function>insert
</function>,
1016 and
<function>rehash
</function>. The container in question is
1017 instantiated with two instrumented template arguments,
1018 with
<classname>__gnu_cxx::throw_allocator_limit
</classname>
1019 as the allocator type, and
1020 with
<classname>__gnu_cxx::throw_type_limit
</classname> as
1021 the value type. This allows the test to loop through
1022 conditional throw points.
1026 The general form demonstrated in
1027 <filename>testsuite/
23_containers/list/requirements/exception/propagation_coherent.cc
1028 </filename>. The instantiating test object is
<classname>__gnu_test::propagation_coherent
</classname> and is detailed in
<filename>testsuite/util/exception/safety.h
</filename>.