From a12b971e9b6b14c3ad29dbd4f5a70bf1fc35c4a2 Mon Sep 17 00:00:00 2001 From: bkoz Date: Tue, 5 Jan 2010 20:51:05 +0000 Subject: 2010-01-05 Benjamin Kosnik * doc/xml/manual/evolution.xml: Update for 4.4 and 4.5 releases. * doc/html: Regenerate. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@155661 138bc75d-0d04-0410-961f-82ee72b054a4 --- libstdc++-v3/doc/html/manual/abi.html | 90 +++--- libstdc++-v3/doc/html/manual/algorithms.html | 8 +- libstdc++-v3/doc/html/manual/api.html | 117 ++++++-- .../doc/html/manual/appendix_contributing.html | 40 +-- libstdc++-v3/doc/html/manual/appendix_free.html | 8 +- libstdc++-v3/doc/html/manual/appendix_gfdl.html | 34 +-- libstdc++-v3/doc/html/manual/appendix_gpl.html | 40 +-- libstdc++-v3/doc/html/manual/appendix_porting.html | 30 +- libstdc++-v3/doc/html/manual/associative.html | 28 +- libstdc++-v3/doc/html/manual/auto_ptr.html | 6 +- libstdc++-v3/doc/html/manual/backwards.html | 86 +++--- libstdc++-v3/doc/html/manual/bitmap_allocator.html | 64 ++--- libstdc++-v3/doc/html/manual/bitset.html | 20 +- libstdc++-v3/doc/html/manual/bk01ix01.html | 7 +- libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html | 4 +- libstdc++-v3/doc/html/manual/bk01pt02pr01.html | 4 +- libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt03ch08.html | 6 +- libstdc++-v3/doc/html/manual/bk01pt05ch13.html | 4 +- libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html | 6 +- libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html | 4 +- libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html | 16 +- libstdc++-v3/doc/html/manual/bk01pt08ch19.html | 6 +- libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html | 8 +- libstdc++-v3/doc/html/manual/bk01pt09ch20.html | 4 +- libstdc++-v3/doc/html/manual/bk01pt09pr02.html | 8 +- libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html | 16 +- libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html | 4 +- libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html | 10 +- libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html | 70 ++--- libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html | 8 +- libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html | 14 +- libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt12ch32s02.html | 26 +- libstdc++-v3/doc/html/manual/bk01pt12ch32s03.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt12ch32s04.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt12ch32s05.html | 12 +- libstdc++-v3/doc/html/manual/bk01pt12ch32s06.html | 18 +- libstdc++-v3/doc/html/manual/bk01pt12ch32s07.html | 302 ++++++++++----------- libstdc++-v3/doc/html/manual/bk01pt12ch34s02.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt12ch34s03.html | 4 +- libstdc++-v3/doc/html/manual/bk01pt12ch41s02.html | 8 +- libstdc++-v3/doc/html/manual/bk01pt12ch41s03.html | 2 +- libstdc++-v3/doc/html/manual/bk01pt12pr03.html | 8 +- libstdc++-v3/doc/html/manual/bugs.html | 24 +- libstdc++-v3/doc/html/manual/codecvt.html | 70 ++--- libstdc++-v3/doc/html/manual/complex.html | 6 +- libstdc++-v3/doc/html/manual/configure.html | 2 +- libstdc++-v3/doc/html/manual/containers.html | 6 +- libstdc++-v3/doc/html/manual/containers_and_c.html | 6 +- libstdc++-v3/doc/html/manual/debug.html | 18 +- libstdc++-v3/doc/html/manual/debug_mode.html | 8 +- libstdc++-v3/doc/html/manual/diagnostics.html | 6 +- .../doc/html/manual/documentation_style.html | 36 +-- libstdc++-v3/doc/html/manual/dynamic_memory.html | 18 +- libstdc++-v3/doc/html/manual/exceptions.html | 4 +- libstdc++-v3/doc/html/manual/ext_algorithms.html | 6 +- libstdc++-v3/doc/html/manual/ext_allocators.html | 20 +- .../doc/html/manual/ext_compile_checks.html | 6 +- libstdc++-v3/doc/html/manual/ext_concurrency.html | 20 +- libstdc++-v3/doc/html/manual/ext_containers.html | 6 +- libstdc++-v3/doc/html/manual/ext_demangling.html | 6 +- libstdc++-v3/doc/html/manual/ext_io.html | 18 +- libstdc++-v3/doc/html/manual/ext_iterators.html | 6 +- libstdc++-v3/doc/html/manual/ext_numerics.html | 4 +- libstdc++-v3/doc/html/manual/ext_utilities.html | 16 +- libstdc++-v3/doc/html/manual/extensions.html | 6 +- libstdc++-v3/doc/html/manual/facets.html | 34 +-- libstdc++-v3/doc/html/manual/fstreams.html | 4 +- libstdc++-v3/doc/html/manual/functors.html | 4 +- .../doc/html/manual/fundamental_types.html | 32 +-- .../manual/generalized_numeric_operations.html | 6 +- libstdc++-v3/doc/html/manual/internals.html | 16 +- libstdc++-v3/doc/html/manual/intro.html | 8 +- libstdc++-v3/doc/html/manual/io.html | 6 +- libstdc++-v3/doc/html/manual/io_and_c.html | 4 +- libstdc++-v3/doc/html/manual/iostream_objects.html | 4 +- libstdc++-v3/doc/html/manual/iterators.html | 6 +- libstdc++-v3/doc/html/manual/license.html | 8 +- libstdc++-v3/doc/html/manual/locales.html | 38 +-- libstdc++-v3/doc/html/manual/localization.html | 6 +- libstdc++-v3/doc/html/manual/make.html | 2 +- libstdc++-v3/doc/html/manual/memory.html | 68 ++--- libstdc++-v3/doc/html/manual/messages.html | 62 ++--- libstdc++-v3/doc/html/manual/numerics.html | 6 +- libstdc++-v3/doc/html/manual/numerics_and_c.html | 4 +- libstdc++-v3/doc/html/manual/pairs.html | 4 +- libstdc++-v3/doc/html/manual/parallel_mode.html | 12 +- libstdc++-v3/doc/html/manual/profile_mode.html | 44 +-- libstdc++-v3/doc/html/manual/sequences.html | 10 +- libstdc++-v3/doc/html/manual/setup.html | 16 +- libstdc++-v3/doc/html/manual/shared_ptr.html | 36 +-- .../doc/html/manual/source_code_style.html | 12 +- .../doc/html/manual/source_design_notes.html | 4 +- .../doc/html/manual/source_organization.html | 4 +- libstdc++-v3/doc/html/manual/spine.html | 14 +- libstdc++-v3/doc/html/manual/status.html | 50 ++-- libstdc++-v3/doc/html/manual/streambufs.html | 4 +- libstdc++-v3/doc/html/manual/strings.html | 6 +- libstdc++-v3/doc/html/manual/stringstreams.html | 4 +- libstdc++-v3/doc/html/manual/support.html | 6 +- libstdc++-v3/doc/html/manual/termination.html | 12 +- libstdc++-v3/doc/html/manual/test.html | 254 +++++++++++++---- libstdc++-v3/doc/html/manual/traits.html | 4 +- libstdc++-v3/doc/html/manual/using.html | 16 +- .../doc/html/manual/using_concurrency.html | 28 +- libstdc++-v3/doc/html/manual/using_exceptions.html | 42 +-- libstdc++-v3/doc/html/manual/using_headers.html | 24 +- libstdc++-v3/doc/html/manual/using_macros.html | 4 +- libstdc++-v3/doc/html/manual/using_namespaces.html | 16 +- libstdc++-v3/doc/html/manual/utilities.html | 6 +- libstdc++-v3/doc/html/manual/vector.html | 4 +- .../doc/html/manual/verbose_termination.html | 6 +- 120 files changed, 1344 insertions(+), 1108 deletions(-) (limited to 'libstdc++-v3/doc/html/manual') diff --git a/libstdc++-v3/doc/html/manual/abi.html b/libstdc++-v3/doc/html/manual/abi.html index 7d11f768464..8bc449bc15c 100644 --- a/libstdc++-v3/doc/html/manual/abi.html +++ b/libstdc++-v3/doc/html/manual/abi.html @@ -1,10 +1,10 @@ -ABI Policy and Guidelines
ABI Policy and Guidelines
Prev Appendix B.  +ABI Policy and Guidelines
ABI Policy and Guidelines
Prev Appendix B.  Porting and Maintenance - Next

ABI Policy and Guidelines

-

The C++ Interface

+

 Next

ABI Policy and Guidelines

+

The C++ Interface

C++ applications often dependent on specific language support routines, say for throwing exceptions, or catching exceptions, and perhaps also dependent on features in the C++ Standard Library. @@ -42,9 +42,9 @@ library ABI, which is the compilation of a given library API by a given compiler ABI. In a nutshell:

- “ + “ library API + compiler ABI = library ABI - ” + ”

The library ABI is mostly of interest for end-users who have unresolved symbols and are linking dynamically to the C++ Standard @@ -58,10 +58,10 @@ given compiler ABI. In a nutshell: To use a specific version of the C++ ABI, one must use a corresponding GNU C++ toolchain (i.e., g++ and libstdc++) that implements the C++ ABI in question. -

Versioning

The C++ interface has evolved throughout the history of the GNU +

Versioning

The C++ interface has evolved throughout the history of the GNU C++ toolchain. With each release, various details have been changed so as to give distinct versions to the C++ interface. -

Goals

Extending existing, stable ABIs. Versioning gives subsequent +

Goals

Extending existing, stable ABIs. Versioning gives subsequent releases of library binaries the ability to add new symbols and add functionality, all the while retaining compatibility with the previous releases in the series. Thus, program binaries linked with the initial @@ -75,7 +75,7 @@ binary in a release series (with additional symbols added), substitute in the initial release of the library binary, and remain link compatible.

Allows multiple, incompatible ABIs to coexist at the same time. -

History

+

History

How can this complexity be managed? What does C++ versioning mean? Because library and compiler changes often make binaries compiled with one version of the GNU tools incompatible with binaries @@ -84,17 +84,17 @@ compatible. easier.

The following techniques are used: -

  1. Release versioning on the libgcc_s.so binary.

    This is implemented via file names and the ELF +

    1. Release versioning on the libgcc_s.so binary.

      This is implemented via file names and the ELF DT_SONAME mechanism (at least on ELF systems). It is versioned as follows: -

      • gcc-3.0.0: libgcc_s.so.1

      • gcc-3.0.1: libgcc_s.so.1

      • gcc-3.0.2: libgcc_s.so.1

      • gcc-3.0.3: libgcc_s.so.1

      • gcc-3.0.4: libgcc_s.so.1

      • gcc-3.1.0: libgcc_s.so.1

      • gcc-3.1.1: libgcc_s.so.1

      • gcc-3.2.0: libgcc_s.so.1

      • gcc-3.2.1: libgcc_s.so.1

      • gcc-3.2.2: libgcc_s.so.1

      • gcc-3.2.3: libgcc_s.so.1

      • gcc-3.3.0: libgcc_s.so.1

      • gcc-3.3.1: libgcc_s.so.1

      • gcc-3.3.2: libgcc_s.so.1

      • gcc-3.3.3: libgcc_s.so.1

      • gcc-3.4.x, gcc-4.[0-3].x: on m68k-linux and +

        • gcc-3.0.0: libgcc_s.so.1

        • gcc-3.0.1: libgcc_s.so.1

        • gcc-3.0.2: libgcc_s.so.1

        • gcc-3.0.3: libgcc_s.so.1

        • gcc-3.0.4: libgcc_s.so.1

        • gcc-3.1.0: libgcc_s.so.1

        • gcc-3.1.1: libgcc_s.so.1

        • gcc-3.2.0: libgcc_s.so.1

        • gcc-3.2.1: libgcc_s.so.1

        • gcc-3.2.2: libgcc_s.so.1

        • gcc-3.2.3: libgcc_s.so.1

        • gcc-3.3.0: libgcc_s.so.1

        • gcc-3.3.1: libgcc_s.so.1

        • gcc-3.3.2: libgcc_s.so.1

        • gcc-3.3.3: libgcc_s.so.1

        • gcc-3.4.x, gcc-4.[0-5].x: on m68k-linux and hppa-linux this is either libgcc_s.so.1 (when configuring --with-sjlj-exceptions) or libgcc_s.so.2. For all - others, this is libgcc_s.so.1.

      • Symbol versioning on the libgcc_s.so binary.

        It is versioned with the following labels and version + others, this is libgcc_s.so.1.

    2. Symbol versioning on the libgcc_s.so binary.

      It is versioned with the following labels and version definitions, where the version definition is the maximum for a particular release. Labels are cumulative. If a particular release is not listed, it has the same version labels as the preceding - release.

      This corresponds to the mapfile: gcc/libgcc-std.ver

      • gcc-3.0.0: GCC_3.0

      • gcc-3.3.0: GCC_3.3

      • gcc-3.3.1: GCC_3.3.1

      • gcc-3.3.2: GCC_3.3.2

      • gcc-3.3.4: GCC_3.3.4

      • gcc-3.4.0: GCC_3.4

      • gcc-3.4.2: GCC_3.4.2

      • gcc-3.4.4: GCC_3.4.4

      • gcc-4.0.0: GCC_4.0.0

      • gcc-4.1.0: GCC_4.1.0

      • gcc-4.2.0: GCC_4.2.0

      • gcc-4.3.0: GCC_4.3.0

      • gcc-4.4.0: GCC_4.4.0

    3. + release.

      This corresponds to the mapfile: gcc/libgcc-std.ver

      • gcc-3.0.0: GCC_3.0

      • gcc-3.3.0: GCC_3.3

      • gcc-3.3.1: GCC_3.3.1

      • gcc-3.3.2: GCC_3.3.2

      • gcc-3.3.4: GCC_3.3.4

      • gcc-3.4.0: GCC_3.4

      • gcc-3.4.2: GCC_3.4.2

      • gcc-3.4.4: GCC_3.4.4

      • gcc-4.0.0: GCC_4.0.0

      • gcc-4.1.0: GCC_4.1.0

      • gcc-4.2.0: GCC_4.2.0

      • gcc-4.3.0: GCC_4.3.0

      • gcc-4.4.0: GCC_4.4.0

    4. Release versioning on the libstdc++.so binary, implemented in the same was as the libgcc_s.so binary above. Listed is the filename: DT_SONAME can be deduced from @@ -106,7 +106,7 @@ compatible. the table below, releases incompatible with the previous one are explicitly noted.

      It is versioned as follows: -

      • gcc-3.0.0: libstdc++.so.3.0.0

      • gcc-3.0.1: libstdc++.so.3.0.1

      • gcc-3.0.2: libstdc++.so.3.0.2

      • gcc-3.0.3: libstdc++.so.3.0.2 (See Note 1)

      • gcc-3.0.4: libstdc++.so.3.0.4

      • gcc-3.1.0: libstdc++.so.4.0.0 (Incompatible with previous)

      • gcc-3.1.1: libstdc++.so.4.0.1

      • gcc-3.2.0: libstdc++.so.5.0.0 (Incompatible with previous)

      • gcc-3.2.1: libstdc++.so.5.0.1

      • gcc-3.2.2: libstdc++.so.5.0.2

      • gcc-3.2.3: libstdc++.so.5.0.3 (See Note 2)

      • gcc-3.3.0: libstdc++.so.5.0.4

      • gcc-3.3.1: libstdc++.so.5.0.5

      • gcc-3.3.2: libstdc++.so.5.0.5

      • gcc-3.3.3: libstdc++.so.5.0.5

      • gcc-3.4.0: libstdc++.so.6.0.0 (Incompatible with previous)

      • gcc-3.4.1: libstdc++.so.6.0.1

      • gcc-3.4.2: libstdc++.so.6.0.2

      • gcc-3.4.3: libstdc++.so.6.0.3

      • gcc-3.4.4: libstdc++.so.6.0.3

      • gcc-3.4.5: libstdc++.so.6.0.3

      • gcc-3.4.6: libstdc++.so.6.0.3

      • gcc-4.0.0: libstdc++.so.6.0.4

      • gcc-4.0.1: libstdc++.so.6.0.5

      • gcc-4.0.2: libstdc++.so.6.0.6

      • gcc-4.0.3: libstdc++.so.6.0.7

      • gcc-4.1.0: libstdc++.so.6.0.7

      • gcc-4.1.1: libstdc++.so.6.0.8

      • gcc-4.1.2: libstdc++.so.6.0.8

      • gcc-4.2.0: libstdc++.so.6.0.9

      • gcc-4.2.1: libstdc++.so.6.0.9 (See Note 3)

      • gcc-4.2.2: libstdc++.so.6.0.9

      • gcc-4.2.3: libstdc++.so.6.0.9

      • gcc-4.2.4: libstdc++.so.6.0.9

      • gcc-4.3.0: libstdc++.so.6.0.10

      • gcc-4.3.1: libstdc++.so.6.0.10

      • gcc-4.3.2: libstdc++.so.6.0.10

      • gcc-4.3.3: libstdc++.so.6.0.10

      • gcc-4.4.0: libstdc++.so.6.0.11

      +

      • gcc-3.0.0: libstdc++.so.3.0.0

      • gcc-3.0.1: libstdc++.so.3.0.1

      • gcc-3.0.2: libstdc++.so.3.0.2

      • gcc-3.0.3: libstdc++.so.3.0.2 (See Note 1)

      • gcc-3.0.4: libstdc++.so.3.0.4

      • gcc-3.1.0: libstdc++.so.4.0.0 (Incompatible with previous)

      • gcc-3.1.1: libstdc++.so.4.0.1

      • gcc-3.2.0: libstdc++.so.5.0.0 (Incompatible with previous)

      • gcc-3.2.1: libstdc++.so.5.0.1

      • gcc-3.2.2: libstdc++.so.5.0.2

      • gcc-3.2.3: libstdc++.so.5.0.3 (See Note 2)

      • gcc-3.3.0: libstdc++.so.5.0.4

      • gcc-3.3.1: libstdc++.so.5.0.5

      • gcc-3.3.2: libstdc++.so.5.0.5

      • gcc-3.3.3: libstdc++.so.5.0.5

      • gcc-3.4.0: libstdc++.so.6.0.0 (Incompatible with previous)

      • gcc-3.4.1: libstdc++.so.6.0.1

      • gcc-3.4.2: libstdc++.so.6.0.2

      • gcc-3.4.3: libstdc++.so.6.0.3

      • gcc-3.4.4: libstdc++.so.6.0.3

      • gcc-3.4.5: libstdc++.so.6.0.3

      • gcc-3.4.6: libstdc++.so.6.0.3

      • gcc-4.0.0: libstdc++.so.6.0.4

      • gcc-4.0.1: libstdc++.so.6.0.5

      • gcc-4.0.2: libstdc++.so.6.0.6

      • gcc-4.0.3: libstdc++.so.6.0.7

      • gcc-4.1.0: libstdc++.so.6.0.7

      • gcc-4.1.1: libstdc++.so.6.0.8

      • gcc-4.1.2: libstdc++.so.6.0.8

      • gcc-4.2.0: libstdc++.so.6.0.9

      • gcc-4.2.1: libstdc++.so.6.0.9 (See Note 3)

      • gcc-4.2.2: libstdc++.so.6.0.9

      • gcc-4.2.3: libstdc++.so.6.0.9

      • gcc-4.2.4: libstdc++.so.6.0.9

      • gcc-4.3.0: libstdc++.so.6.0.10

      • gcc-4.3.1: libstdc++.so.6.0.10

      • gcc-4.3.2: libstdc++.so.6.0.10

      • gcc-4.3.3: libstdc++.so.6.0.10

      • gcc-4.3.4: libstdc++.so.6.0.10

      • gcc-4.4.0: libstdc++.so.6.0.11

      • gcc-4.4.1: libstdc++.so.6.0.12

      • gcc-4.4.2: libstdc++.so.6.0.13

      • gcc-4.5.0: libstdc++.so.6.0.14

      Note 1: Error should be libstdc++.so.3.0.3.

      Note 2: Not strictly required. @@ -114,7 +114,7 @@ compatible. Note 3: This release (but not previous or subsequent) has one known incompatibility, see 33678 in the GCC bug database. -

    5. Symbol versioning on the libstdc++.so binary.

      mapfile: libstdc++/config/linker-map.gnu

      It is versioned with the following labels and version +

    6. Symbol versioning on the libstdc++.so binary.

      mapfile: libstdc++/config/linker-map.gnu

      It is versioned with the following labels and version definitions, where the version definition is the maximum for a particular release. Note, only symbol which are newly introduced will use the maximum version definition. Thus, for release series @@ -124,7 +124,7 @@ compatible. GLIBCPP_3.2 for symbols that were introduced in the gcc-3.2.0 release.) If a particular release is not listed, it has the same version labels as the preceding release. -

      • gcc-3.0.0: (Error, not versioned)

      • gcc-3.0.1: (Error, not versioned)

      • gcc-3.0.2: (Error, not versioned)

      • gcc-3.0.3: (Error, not versioned)

      • gcc-3.0.4: (Error, not versioned)

      • gcc-3.1.0: GLIBCPP_3.1, CXXABI_1

      • gcc-3.1.1: GLIBCPP_3.1, CXXABI_1

      • gcc-3.2.0: GLIBCPP_3.2, CXXABI_1.2

      • gcc-3.2.1: GLIBCPP_3.2.1, CXXABI_1.2

      • gcc-3.2.2: GLIBCPP_3.2.2, CXXABI_1.2

      • gcc-3.2.3: GLIBCPP_3.2.2, CXXABI_1.2

      • gcc-3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1

      • gcc-3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1

      • gcc-3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1

      • gcc-3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1

      • gcc-3.4.0: GLIBCXX_3.4, CXXABI_1.3

      • gcc-3.4.1: GLIBCXX_3.4.1, CXXABI_1.3

      • gcc-3.4.2: GLIBCXX_3.4.2

      • gcc-3.4.3: GLIBCXX_3.4.3

      • gcc-4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1

      • gcc-4.0.1: GLIBCXX_3.4.5

      • gcc-4.0.2: GLIBCXX_3.4.6

      • gcc-4.0.3: GLIBCXX_3.4.7

      • gcc-4.1.1: GLIBCXX_3.4.8

      • gcc-4.2.0: GLIBCXX_3.4.9

      • gcc-4.3.0: GLIBCXX_3.4.10, CXXABI_1.3.2

      • gcc-4.4.0: GLIBCXX_3.4.11, CXXABI_1.3.3

    7. Incremental bumping of a compiler pre-defined macro, +

      • gcc-3.0.0: (Error, not versioned)

      • gcc-3.0.1: (Error, not versioned)

      • gcc-3.0.2: (Error, not versioned)

      • gcc-3.0.3: (Error, not versioned)

      • gcc-3.0.4: (Error, not versioned)

      • gcc-3.1.0: GLIBCPP_3.1, CXXABI_1

      • gcc-3.1.1: GLIBCPP_3.1, CXXABI_1

      • gcc-3.2.0: GLIBCPP_3.2, CXXABI_1.2

      • gcc-3.2.1: GLIBCPP_3.2.1, CXXABI_1.2

      • gcc-3.2.2: GLIBCPP_3.2.2, CXXABI_1.2

      • gcc-3.2.3: GLIBCPP_3.2.2, CXXABI_1.2

      • gcc-3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1

      • gcc-3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1

      • gcc-3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1

      • gcc-3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1

      • gcc-3.4.0: GLIBCXX_3.4, CXXABI_1.3

      • gcc-3.4.1: GLIBCXX_3.4.1, CXXABI_1.3

      • gcc-3.4.2: GLIBCXX_3.4.2

      • gcc-3.4.3: GLIBCXX_3.4.3

      • gcc-4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1

      • gcc-4.0.1: GLIBCXX_3.4.5

      • gcc-4.0.2: GLIBCXX_3.4.6

      • gcc-4.0.3: GLIBCXX_3.4.7

      • gcc-4.1.1: GLIBCXX_3.4.8

      • gcc-4.2.0: GLIBCXX_3.4.9

      • gcc-4.3.0: GLIBCXX_3.4.10, CXXABI_1.3.2

      • gcc-4.4.0: GLIBCXX_3.4.11, CXXABI_1.3.3

      • gcc-4.4.1: GLIBCXX_3.4.12, CXXABI_1.3.3

      • gcc-4.4.2: GLIBCXX_3.4.13, CXXABI_1.3.3

      • gcc-4.5.0: GLIBCXX_3.4.14, CXXABI_1.3.4

    8. Incremental bumping of a compiler pre-defined macro, __GXX_ABI_VERSION. This macro is defined as the version of the compiler v3 ABI, with g++ 3.0.x being version 100. This macro will be automatically defined whenever g++ is used (the curious can @@ -136,11 +136,11 @@ compatible. '-fabi-version' command line option.

      It is versioned as follows, where 'n' is given by '-fabi-version=n': -

      • gcc-3.0.x: 100

      • gcc-3.1.x: 100 (Error, should be 101)

      • gcc-3.2.x: 102

      • gcc-3.3.x: 102

      • gcc-3.4.x, gcc-4.[0-3].x: 102 (when n=1)

      • gcc-3.4.x, gcc-4.[0-3].x: 1000 + n (when n>1)

      • gcc-3.4.x, gcc-4.[0-3].x: 999999 (when n=0)

    9. Changes to the default compiler option for +

      • gcc-3.0.x: 100

      • gcc-3.1.x: 100 (Error, should be 101)

      • gcc-3.2.x: 102

      • gcc-3.3.x: 102

      • gcc-3.4.x, gcc-4.[0-5].x: 102 (when n=1)

      • gcc-3.4.x, gcc-4.[0-5].x: 1000 + n (when n>1)

      • gcc-3.4.x, gcc-4.[0-5].x: 999999 (when n=0)

    10. Changes to the default compiler option for -fabi-version.

      It is versioned as follows: -

      • gcc-3.0.x: (Error, not versioned)

      • gcc-3.1.x: (Error, not versioned)

      • gcc-3.2.x: -fabi-version=1

      • gcc-3.3.x: -fabi-version=1

      • gcc-3.4.x, gcc-4.[0-3].x: -fabi-version=2 (Incompatible with previous)

    11. Incremental bumping of a library pre-defined macro. For releases +

      • gcc-3.0.x: (Error, not versioned)

      • gcc-3.1.x: (Error, not versioned)

      • gcc-3.2.x: -fabi-version=1

      • gcc-3.3.x: -fabi-version=1

      • gcc-3.4.x, gcc-4.[0-5].x: -fabi-version=2 (Incompatible with previous)

    12. Incremental bumping of a library pre-defined macro. For releases before 3.4.0, the macro is __GLIBCPP__. For later releases, it's __GLIBCXX__. (The libstdc++ project generously changed from CPP to CXX throughout its source to allow the "C" pre-processor the CPP @@ -153,7 +153,7 @@ compatible. the same value as gcc/DATESTAMP.)

      It is versioned as follows: -

      • gcc-3.0.0: 20010615

      • gcc-3.0.1: 20010819

      • gcc-3.0.2: 20011023

      • gcc-3.0.3: 20011220

      • gcc-3.0.4: 20020220

      • gcc-3.1.0: 20020514

      • gcc-3.1.1: 20020725

      • gcc-3.2.0: 20020814

      • gcc-3.2.1: 20021119

      • gcc-3.2.2: 20030205

      • gcc-3.2.3: 20030422

      • gcc-3.3.0: 20030513

      • gcc-3.3.1: 20030804

      • gcc-3.3.2: 20031016

      • gcc-3.3.3: 20040214

      • gcc-3.4.0: 20040419

      • gcc-3.4.1: 20040701

      • gcc-3.4.2: 20040906

      • gcc-3.4.3: 20041105

      • gcc-3.4.4: 20050519

      • gcc-3.4.5: 20051201

      • gcc-3.4.6: 20060306

      • gcc-4.0.0: 20050421

      • gcc-4.0.1: 20050707

      • gcc-4.0.2: 20050921

      • gcc-4.0.3: 20060309

      • gcc-4.1.0: 20060228

      • gcc-4.1.1: 20060524

      • gcc-4.1.2: 20070214

      • gcc-4.2.0: 20070514

      • gcc-4.2.1: 20070719

      • gcc-4.2.2: 20071007

      • gcc-4.2.3: 20080201

      • gcc-4.2.4: 20080519

      • gcc-4.3.0: 20080306

      • gcc-4.3.1: 20080606

      • gcc-4.3.2: 20080827

      • gcc-4.3.3: 20090124

      • gcc-4.4.0: 20090421

    13. +

      • gcc-3.0.0: 20010615

      • gcc-3.0.1: 20010819

      • gcc-3.0.2: 20011023

      • gcc-3.0.3: 20011220

      • gcc-3.0.4: 20020220

      • gcc-3.1.0: 20020514

      • gcc-3.1.1: 20020725

      • gcc-3.2.0: 20020814

      • gcc-3.2.1: 20021119

      • gcc-3.2.2: 20030205

      • gcc-3.2.3: 20030422

      • gcc-3.3.0: 20030513

      • gcc-3.3.1: 20030804

      • gcc-3.3.2: 20031016

      • gcc-3.3.3: 20040214

      • gcc-3.4.0: 20040419

      • gcc-3.4.1: 20040701

      • gcc-3.4.2: 20040906

      • gcc-3.4.3: 20041105

      • gcc-3.4.4: 20050519

      • gcc-3.4.5: 20051201

      • gcc-3.4.6: 20060306

      • gcc-4.0.0: 20050421

      • gcc-4.0.1: 20050707

      • gcc-4.0.2: 20050921

      • gcc-4.0.3: 20060309

      • gcc-4.1.0: 20060228

      • gcc-4.1.1: 20060524

      • gcc-4.1.2: 20070214

      • gcc-4.2.0: 20070514

      • gcc-4.2.1: 20070719

      • gcc-4.2.2: 20071007

      • gcc-4.2.3: 20080201

      • gcc-4.2.4: 20080519

      • gcc-4.3.0: 20080306

      • gcc-4.3.1: 20080606

      • gcc-4.3.2: 20080827

      • gcc-4.3.3: 20090124

      • gcc-4.4.0: 20090421

      • gcc-4.4.1: 20090722

      • gcc-4.4.2: 20091015

    14. Incremental bumping of a library pre-defined macro, _GLIBCPP_VERSION. This macro is defined as the released version of the library, as a string literal. This is only implemented in @@ -166,7 +166,7 @@ compatible. of config.h.

      It is versioned as follows: -

      • gcc-3.0.0: "3.0.0"

      • gcc-3.0.1: "3.0.0" (Error, should be "3.0.1")

      • gcc-3.0.2: "3.0.0" (Error, should be "3.0.2")

      • gcc-3.0.3: "3.0.0" (Error, should be "3.0.3")

      • gcc-3.0.4: "3.0.0" (Error, should be "3.0.4")

      • gcc-3.1.0: "3.1.0"

      • gcc-3.1.1: "3.1.1"

      • gcc-3.2.0: "3.2"

      • gcc-3.2.1: "3.2.1"

      • gcc-3.2.2: "3.2.2"

      • gcc-3.2.3: "3.2.3"

      • gcc-3.3.0: "3.3"

      • gcc-3.3.1: "3.3.1"

      • gcc-3.3.2: "3.3.2"

      • gcc-3.3.3: "3.3.3"

      • gcc-3.4.x: "version-unused"

      • gcc-4.[0-3].x: "version-unused"

    15. +

      • gcc-3.0.0: "3.0.0"

      • gcc-3.0.1: "3.0.0" (Error, should be "3.0.1")

      • gcc-3.0.2: "3.0.0" (Error, should be "3.0.2")

      • gcc-3.0.3: "3.0.0" (Error, should be "3.0.3")

      • gcc-3.0.4: "3.0.0" (Error, should be "3.0.4")

      • gcc-3.1.0: "3.1.0"

      • gcc-3.1.1: "3.1.1"

      • gcc-3.2.0: "3.2"

      • gcc-3.2.1: "3.2.1"

      • gcc-3.2.2: "3.2.2"

      • gcc-3.2.3: "3.2.3"

      • gcc-3.3.0: "3.3"

      • gcc-3.3.1: "3.3.1"

      • gcc-3.3.2: "3.3.2"

      • gcc-3.3.3: "3.3.3"

      • gcc-3.4.x: "version-unused"

      • gcc-4.[0-5].x: "version-unused"

    16. Matching each specific C++ compiler release to a specific set of C++ include files. This is only implemented in gcc-3.1.1 releases and higher. @@ -178,13 +178,13 @@ compatible. file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before gcc-3.4.0).

      C++ includes are versioned as follows: -

      • gcc-3.0.0: include/g++-v3

      • gcc-3.0.1: include/g++-v3

      • gcc-3.0.2: include/g++-v3

      • gcc-3.0.3: include/g++-v3

      • gcc-3.0.4: include/g++-v3

      • gcc-3.1.0: include/g++-v3

      • gcc-3.1.1: include/c++/3.1.1

      • gcc-3.2.0: include/c++/3.2

      • gcc-3.2.1: include/c++/3.2.1

      • gcc-3.2.2: include/c++/3.2.2

      • gcc-3.2.3: include/c++/3.2.3

      • gcc-3.3.0: include/c++/3.3

      • gcc-3.3.1: include/c++/3.3.1

      • gcc-3.3.2: include/c++/3.3.2

      • gcc-3.3.3: include/c++/3.3.3

      • gcc-3.4.0: include/c++/3.4.0

      • gcc-3.4.1: include/c++/3.4.1

      • gcc-3.4.2: include/c++/3.4.2

      • gcc-3.4.3: include/c++/3.4.3

      • gcc-3.4.4: include/c++/3.4.4

      • gcc-3.4.5: include/c++/3.4.5

      • gcc-3.4.6: include/c++/3.4.6

      • gcc-4.0.0: include/c++/4.0.0

      • gcc-4.0.1: include/c++/4.0.1

      • gcc-4.0.2: include/c++/4.0.2

      • gcc-4.0.3: include/c++/4.0.3

      • gcc-4.1.0: include/c++/4.1.0

      • gcc-4.1.1: include/c++/4.1.1

      • gcc-4.1.2: include/c++/4.1.2

      • gcc-4.2.0: include/c++/4.2.0

      • gcc-4.2.1: include/c++/4.2.1

      • gcc-4.2.2: include/c++/4.2.2

      • gcc-4.2.3: include/c++/4.2.3

      • gcc-4.2.4: include/c++/4.2.4

      • gcc-4.3.0: include/c++/4.3.0

      • gcc-4.3.1: include/c++/4.3.1

      • gcc-4.3.3: include/c++/4.3.3

      • gcc-4.4.0: include/c++/4.4.0

    +

    • gcc-3.0.0: include/g++-v3

    • gcc-3.0.1: include/g++-v3

    • gcc-3.0.2: include/g++-v3

    • gcc-3.0.3: include/g++-v3

    • gcc-3.0.4: include/g++-v3

    • gcc-3.1.0: include/g++-v3

    • gcc-3.1.1: include/c++/3.1.1

    • gcc-3.2.0: include/c++/3.2

    • gcc-3.2.1: include/c++/3.2.1

    • gcc-3.2.2: include/c++/3.2.2

    • gcc-3.2.3: include/c++/3.2.3

    • gcc-3.3.0: include/c++/3.3

    • gcc-3.3.1: include/c++/3.3.1

    • gcc-3.3.2: include/c++/3.3.2

    • gcc-3.3.3: include/c++/3.3.3

    • gcc-3.4.0: include/c++/3.4.0

    • gcc-3.4.1: include/c++/3.4.1

    • gcc-3.4.2: include/c++/3.4.2

    • gcc-3.4.3: include/c++/3.4.3

    • gcc-3.4.4: include/c++/3.4.4

    • gcc-3.4.5: include/c++/3.4.5

    • gcc-3.4.6: include/c++/3.4.6

    • gcc-4.0.0: include/c++/4.0.0

    • gcc-4.0.1: include/c++/4.0.1

    • gcc-4.0.2: include/c++/4.0.2

    • gcc-4.0.3: include/c++/4.0.3

    • gcc-4.1.0: include/c++/4.1.0

    • gcc-4.1.1: include/c++/4.1.1

    • gcc-4.1.2: include/c++/4.1.2

    • gcc-4.2.0: include/c++/4.2.0

    • gcc-4.2.1: include/c++/4.2.1

    • gcc-4.2.2: include/c++/4.2.2

    • gcc-4.2.3: include/c++/4.2.3

    • gcc-4.2.4: include/c++/4.2.4

    • gcc-4.3.0: include/c++/4.3.0

    • gcc-4.3.1: include/c++/4.3.1

    • gcc-4.3.3: include/c++/4.3.3

    • gcc-4.3.4: include/c++/4.3.4

    • gcc-4.4.0: include/c++/4.4.0

    • gcc-4.4.1: include/c++/4.4.1

    • gcc-4.4.2: include/c++/4.4.2

    • gcc-4.5.0: include/c++/4.5.0

Taken together, these techniques can accurately specify interface and implementation changes in the GNU C++ tools themselves. Used properly, they allow both the GNU C++ tools implementation, and programs using them, an evolving yet controlled development that maintains backward compatibility. -

Prerequisites

+

Prerequisites

Minimum environment that supports a versioned ABI: A supported dynamic linker, a GNU linker of sufficient vintage to understand demangled C++ name globbing (ld), a shared executable compiled @@ -198,7 +198,7 @@ compatible. Most modern Linux and BSD versions, particularly ones using gcc-3.1.x tools and more recent vintages, will meet the requirements above. -

Configuring

+

Configuring

It turns out that most of the configure options that change default behavior will impact the mangled names of exported symbols, and thus impact versioning and compatibility. @@ -216,7 +216,7 @@ compatible. attempts to make sure that all the requirement for symbol versioning are in place. For more information, please consult acinclude.m4. -

Checking Active

+

Checking Active

When the GNU C++ library is being built with symbol versioning on, you should see the following at configure time for libstdc++: @@ -252,29 +252,29 @@ If you see symbols in the resulting output with "GLIBCXX_3" as part of the name, then the executable is versioned. Here's an example:

U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4 -

Allowed Changes

+

Allowed Changes

The following will cause the library minor version number to increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5". -

  1. Adding an exported global or static data member

  2. Adding an exported function, static or non-virtual member function

  3. Adding an exported symbol or symbols by additional instantiations

+

  1. Adding an exported global or static data member

  2. Adding an exported function, static or non-virtual member function

  3. Adding an exported symbol or symbols by additional instantiations

Other allowed changes are possible. -

Prohibited Changes

+

Prohibited Changes

The following non-exhaustive list will cause the library major version number to increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.4.0.0". -

  1. Changes in the gcc/g++ compiler ABI

  2. Changing size of an exported symbol

  3. Changing alignment of an exported symbol

  4. Changing the layout of an exported symbol

  5. Changing mangling on an exported symbol

  6. Deleting an exported symbol

  7. Changing the inheritance properties of a type by adding or removing - base classes

  8. +

    1. Changes in the gcc/g++ compiler ABI

    2. Changing size of an exported symbol

    3. Changing alignment of an exported symbol

    4. Changing the layout of an exported symbol

    5. Changing mangling on an exported symbol

    6. Deleting an exported symbol

    7. Changing the inheritance properties of a type by adding or removing + base classes

    8. Changing the size, alignment, or layout of types specified in the C++ standard. These may not necessarily be instantiated or otherwise exported in the library binary, and include all the required locale facets, as well as things like std::basic_streambuf, et al. -

    9. Adding an explicit copy constructor or destructor to a +

    10. Adding an explicit copy constructor or destructor to a class that would otherwise have implicit versions. This will change the way the compiler deals with this class in by-value return statements or parameters: instead of being passing instances of this class in registers, the compiler will be forced to use memory. See this part of the C++ ABI documentation for further details. -

Implementation

  1. +

Implementation

  1. Separation of interface and implementation

    This is accomplished by two techniques that separate the API from @@ -301,7 +301,7 @@ class in registers, the compiler will be forced to use memory. See

    Namespaces linking symbol definitions to export mapfiles

    All symbols in the shared library binary are processed by a @@ -320,9 +320,9 @@ class in registers, the compiler will be forced to use memory. See namespace __gnu_cxx

    Defaults to not exporting any symbols in label GLIBCXX, select items are allowed to be visible.

    namespace __gnu_internal

    Defaults to not exported, no items are allowed to be visible.

    namespace __cxxabiv1, aliased to namespace abi

    Defaults to not exporting any symbols in label CXXABI, select items are allowed to be visible.

-

  • Freezing the API

    Disallowed changes, as above, are not made on a stable release +

  • Freezing the API

    Disallowed changes, as above, are not made on a stable release branch. Enforcement tends to be less strict with GNU extensions that -standard includes.

    • Testing

    Single ABI Testing

    +standard includes.

    Testing

    Single ABI Testing

    Testing for GNU C++ ABI changes is composed of two distinct areas: testing the C++ compiler (g++) for compiler changes, and testing the C++ library (libstdc++) for library changes. @@ -388,7 +388,7 @@ and other detailed data is not displayed with this flag.

    Perhaps there are other C++ ABI checkers. If so, please notify us. We'd like to know about them! -

    Multiple ABI Testing

    +

    Multiple ABI Testing

    A "C" application, dynamically linked to two shared libraries, liba, libb. The dependent library liba is C++ shared library compiled with gcc-3.3.x, and uses io, exceptions, locale, etc. The dependent library @@ -451,7 +451,7 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. This resulting binary, when executed, will be able to safely use code from both liba, and the dependent libstdc++.so.6, and libb, with the dependent libstdc++.so.5. -

    Outstanding Issues

    +

    Outstanding Issues

    Some features in the C++ language make versioning especially difficult. In particular, compiler generated constructs such as implicit instantiations for templates, typeinfo information, and @@ -464,56 +464,56 @@ gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so. 24660: versioning weak symbols in libstdc++

    19664: libstdc++ headers should have pop/push of the visibility around the declarations -

    Bibliography

    +

    Bibliography

    ABIcheck, a vague idea of checking ABI compatibility . - .

    + .

    C++ ABI Reference . - .

    + .

    Intel® Compilers for Linux* -Compatibility with the GNU Compilers . - .

    + .

    Sun Solaris 2.9 : Linker and Libraries Guide (document 816-1386) . - .

    + .

    Sun Solaris 2.9 : C++ Migration Guide (document 816-2459) . - .

    + .

    How to Write Shared Libraries . Ulrich Drepper. - .

    + .

    C++ ABI for the ARM Architecture . - .

    + .

    Dynamic Shared Objects: Survey and Issues . ISO C++ J16/06-0046 . Benjamin Kosnik. - .

    + .

    Versioning With Namespaces . ISO C++ J16/06-0083 . Benjamin Kosnik. - .

    + .

    Binary Compatibility of Shared Libraries Implemented in C++ on GNU/Linux Systems . SYRCoSE 2009 diff --git a/libstdc++-v3/doc/html/manual/algorithms.html b/libstdc++-v3/doc/html/manual/algorithms.html index aaaa42c27ef..ea42224b5db 100644 --- a/libstdc++-v3/doc/html/manual/algorithms.html +++ b/libstdc++-v3/doc/html/manual/algorithms.html @@ -1,9 +1,9 @@ -Part IX.  Algorithms

    Part IX.  +Part IX.  Algorithms
    Part IX.  Algorithms -
    Prev The GNU C++ Library Next

    Part IX.  +

    Prev The GNU C++ Library Next

    Part IX.  Algorithms - -

    Table of Contents

    20. Mutating
    swap
    Specializations
    Prev Up Next
    One Past the End Home 
    + +

    Table of Contents

    20. Mutating
    swap
    Specializations
    Prev Up Next
    One Past the End Home 
    diff --git a/libstdc++-v3/doc/html/manual/api.html b/libstdc++-v3/doc/html/manual/api.html index f0f0e271f1a..56db4d32412 100644 --- a/libstdc++-v3/doc/html/manual/api.html +++ b/libstdc++-v3/doc/html/manual/api.html @@ -1,11 +1,11 @@ -API Evolution and Deprecation History
    API Evolution and Deprecation History
    Prev Appendix B.  +API Evolution and Deprecation History
    API Evolution and Deprecation History
    Prev Appendix B.  Porting and Maintenance - Next

    API Evolution and Deprecation History

    +

    		 Next

    API Evolution and Deprecation History

    A list of user-visible changes, in chronological order -

    3.0

    +

    3.0

    Extensions moved to include/ext.

    Include files from the SGI/HP sources that pre-date the ISO standard @@ -14,7 +14,7 @@ the include/backward directory and a deprecated wa is added that notifies on inclusion (-Wno-deprecated deactivates the warning.)

    Deprecated include backward/strstream added.

    Removal of include builtinbuf.h, indstream.h, parsestream.h, PlotFile.h, SFile.h, stdiostream.h, and stream.h. -

    3.1

    +

    3.1

    Extensions from SGI/HP moved from namespace std to namespace __gnu_cxx. As part of this, the following @@ -26,15 +26,15 @@ Extensions to basic_filebuf introduced: ext/rb_tree.

    Removal of ext/tree, moved to backward/tree.h. -

    3.2

    +

    3.2

    Symbol versioning introduced for shared library.

    Removal of include backward/strstream.h.

    Allocator changes. Change __malloc_alloc to malloc_allocator and __new_alloc to new_allocator.

    For GCC releases from 2.95 through the 3.1 series, defining __USE_MALLOC on the gcc command line would change the default allocation strategy to instead use malloc and free. (This same functionality is now spelled _GLIBCXX_FORCE_NEW, see this page for details. -

    Error handling in iostreams cleaned up, made consistent.

    3.3

    -

    3.4

    +

    Error handling in iostreams cleaned up, made consistent.

    3.3

    +

    3.4

    Large file support.

    Extensions for generic characters and char_traits added in ext/pod_char_traits.h. @@ -75,11 +75,11 @@ _Alloc_traits have been removed. __alloc to select an underlying allocator that satisfied memory allocation requests. The selection of this underlying allocator was not user-configurable. -

    Table B.1. Extension Allocators

    Allocator (3.4)Header (3.4)Allocator (3.[0-3])Header (3.[0-3])
    __gnu_cxx::new_allocator<T>ext/new_allocator.hstd::__new_allocmemory
    __gnu_cxx::malloc_allocator<T>ext/malloc_allocator.hstd::__malloc_alloc_template<int>memory
    __gnu_cxx::debug_allocator<T>ext/debug_allocator.hstd::debug_alloc<T>memory
    __gnu_cxx::__pool_alloc<T>ext/pool_allocator.hstd::__default_alloc_template<bool,int>memory
    __gnu_cxx::__mt_alloc<T>ext/mt_allocator.h
    __gnu_cxx::bitmap_allocator<T>ext/bitmap_allocator.h

    Releases after gcc-3.4 have continued to add to the collection +

    Table B.1. Extension Allocators

    Allocator (3.4)Header (3.4)Allocator (3.[0-3])Header (3.[0-3])
    __gnu_cxx::new_allocator<T>ext/new_allocator.hstd::__new_allocmemory
    __gnu_cxx::malloc_allocator<T>ext/malloc_allocator.hstd::__malloc_alloc_template<int>memory
    __gnu_cxx::debug_allocator<T>ext/debug_allocator.hstd::debug_alloc<T>memory
    __gnu_cxx::__pool_alloc<T>ext/pool_allocator.hstd::__default_alloc_template<bool,int>memory
    __gnu_cxx::__mt_alloc<T>ext/mt_allocator.h
    __gnu_cxx::bitmap_allocator<T>ext/bitmap_allocator.h

    Releases after gcc-3.4 have continued to add to the collection of available allocators. All of these new allocators are standard-style. The following table includes details, along with the first released version of GCC that included the extension allocator. -

    Table B.2. Extension Allocators Continued

    AllocatorIncludeVersion
    __gnu_cxx::array_allocator<T>ext/array_allocator.h4.0.0
    __gnu_cxx::throw_allocator<T>ext/throw_allocator.h4.2.0

    +

    Table B.2. Extension Allocators Continued

    AllocatorIncludeVersion
    __gnu_cxx::array_allocator<T>ext/array_allocator.h4.0.0
    __gnu_cxx::throw_allocator<T>ext/throw_allocator.h4.2.0

    Debug mode first appears.

    Precompiled header support PCH support. @@ -89,7 +89,7 @@ Macro guard for changed, from _GLIBCPP_ to ext/stdio_sync_filebuf.h added.

    Extension ext/demangle.h added. -

    4.0

    +

    4.0

    TR1 features first appear.

    @@ -98,14 +98,14 @@ Extension allocator ext/array_allocator.h added. Extension codecvt specializations moved to ext/codecvt_specializations.h.

    Removal of ext/demangle.h. -

    4.1

    +

    4.1

    Removal of cassert from all standard headers: now has to be explicitly included for std::assert calls.

    Extensions for policy-based data structures first added. New includes, types, namespace pb_assoc.

    Extensions for typelists added in ext/typelist.h.

    Extension for policy-based basic_string first added: __gnu_cxx::__versa_string in ext/vstring.h. -

    4.2

    +

    4.2

    Default visibility attributes applied to namespace std. Support for -fvisibility.

    TR1 random, complex, and C compatibility headers added.

    Extensions for concurrent programming consolidated into ext/concurrence.h and ext/atomicity.h, @@ -120,24 +120,25 @@ types, namespace moved to __pb_ds. std::__debug and extensions in namespace __gnu_cxx::__debug.

    Extensions added: ext/typelist.h and ext/throw_allocator.h. -

    4.3

    +

    4.3

    C++0X features first appear. -

    TR1 regex and cmath's mathematical special function added.

    +

    TR1 regex and cmath's mathematical special function added. +

    Backward include edit. -

    • Removed

      +

      • Removed

        algobase.h algo.h alloc.h bvector.h complex.h defalloc.h deque.h fstream.h function.h hash_map.h hash_set.h hashtable.h heap.h iomanip.h iostream.h istream.h iterator.h list.h map.h multimap.h multiset.h new.h ostream.h pair.h queue.h rope.h set.h slist.h stack.h streambuf.h stream.h tempbuf.h tree.h vector.h -

      • Added

        +

      • Added

        hash_map and hash_set -

      • Added in C++0x

        +

      • Added in C++0x

        auto_ptr.h and binders.h

      Header dependency streamlining. -

      • algorithm no longer includes climits, cstring, or iosfwd

      • bitset no longer includes istream or ostream, adds iosfwd

      • functional no longer includes cstddef

      • iomanip no longer includes istream, istream, or functional, adds ioswd

      • numeric no longer includes iterator

      • string no longer includes algorithm or memory

      • valarray no longer includes numeric or cstdlib

      • tr1/hashtable no longer includes memory or functional

      • tr1/memory no longer includes algorithm

      • tr1/random no longer includes algorithm or fstream

      +

      • algorithm no longer includes climits, cstring, or iosfwd

      • bitset no longer includes istream or ostream, adds iosfwd

      • functional no longer includes cstddef

      • iomanip no longer includes istream, istream, or functional, adds ioswd

      • numeric no longer includes iterator

      • string no longer includes algorithm or memory

      • valarray no longer includes numeric or cstdlib

      • tr1/hashtable no longer includes memory or functional

      • tr1/memory no longer includes algorithm

      • tr1/random no longer includes algorithm or fstream

      Debug mode for unordered_map and unordered_set.

      Parallel mode first appears. @@ -151,4 +152,84 @@ Parallel mode first appears. PCH binary files no longer installed. Instead, the source files are installed.

      Namespace pb_ds moved to __gnu_pb_ds. +

    4.4

    +

    +C++0X features. +

    • + Added. +

      + atomic, + chrono, + condition_variable, + forward_list, + initializer_list, + mutex, + ratio, + thread +

    • + Updated and improved. +

      + algorithm, + system_error, + type_traits +

    • + Use of the GNU extension namespace association converted to inline namespaces. +

    • + Preliminary support for initializer_list + and defaulted and deleted constructors in container classes. +

    • + unique_ptr. +

    • + Support for new character types char16_t + and char32_t added + to char_traits, basic_string, numeric_limits, + and assorted compile-time type traits. +

    • + Support for string conversions to_string + and to_wstring. +

    • + Member functions taking string arguments were added to iostreams + including basic_filebuf, basic_ofstream, + and basic_ifstream. +

    • + Exception propagation support, + including exception_ptr, current_exception, copy_exception, + and rethrow_exception. +

    +Uglification of try to __try +and catch to __catch. +

    +Audit of internal mutex usage, conversion to funtions returning static +local mutex. +

    Extensions +added: ext/pointer.h +and ext/extptr_allocator.h. Support +for non-standard pointer types has been added +to vector +and forward_list. +

    4.5

    +

    +C++0X features. +

    • + Added. +

      + future, + random +

    • + Updated and improved. +

      + atomic, + system_error, + type_traits +

    • + Add support for explicit operators and standard layout types. +

    +Profile mode first appears. +

    +Support for decimal floating-point arithmetic, including decimal32, decimal64, and decimal128. +

    +Python pretty-printers are added for use with appropriately-advanced versions of gdb. +

    +Audit for application of function attributes notrow, const, pure, and noreturn. +

    Extensions modified: ext/throw_allocator.h. In addition, experimental support was added for random serialization operators.

    Prev Up Next
    ABI Policy and Guidelines Home Backwards Compatibility
    diff --git a/libstdc++-v3/doc/html/manual/appendix_contributing.html b/libstdc++-v3/doc/html/manual/appendix_contributing.html index b54faf1b14d..e58318e2e09 100644 --- a/libstdc++-v3/doc/html/manual/appendix_contributing.html +++ b/libstdc++-v3/doc/html/manual/appendix_contributing.html @@ -1,17 +1,17 @@ -Appendix A.  Contributing
    Appendix A.  +Appendix A.  Contributing
    Appendix A.  Contributing -
    Prev The GNU C++ Library Next

    Appendix A.  +

    Prev The GNU C++ Library Next

    Appendix A.  Contributing - +

    Table of Contents

    Contributor Checklist
    Reading
    Assignment
    Getting Sources
    Submitting Patches
    Directory Layout and Source Conventions
    Coding Style
    Bad Identifiers
    By Example
    Documentation Style
    Doxygen
    Docbook
    Design Notes

    The GNU C++ Library follows an open development model. Active contributors are assigned maintainer-ship responsibility, and given write access to the source repository. First time contributors should follow this procedure: -

    Contributor Checklist

    Reading

    • +

      Contributor Checklist

      Reading

      • Get and read the relevant sections of the C++ language specification. Copies of the full ISO 14882 standard are available on line via the ISO mirror site for committee @@ -24,30 +24,30 @@ here. (And if you've already registered with them, clicking this link will take you to directly to the place where you can buy the standard on-line.) -

      • +

      • The library working group bugs, and known defects, can be obtained here: http://www.open-std.org/jtc1/sc22/wg21 -

      • +

      • The newsgroup dedicated to standardization issues is comp.std.c++: this FAQ for this group is quite useful and can be found here . -

      • +

      • Peruse the GNU Coding Standards, and chuckle when you hit the part - about “Using Languages Other Than C”. -

      • + about “Using Languages Other Than C”. +

      • Be familiar with the extensions that preceded these general GNU rules. These style issues for libstdc++ can be found here. -

      • +

      • And last but certainly not least, read the library-specific information found here. -

      Assignment

      +

    Assignment

    Small changes can be accepted without a copyright assignment form on file. New code and additions to the library need completed copyright assignment form on file at the FSF. Note: your employer may be required @@ -56,10 +56,10 @@ Historically, the libstdc++ assignment form added the following question:

    - “ + “ Which Belgian comic book character is better, Tintin or Asterix, and why? - ” + ”

    While not strictly necessary, humoring the maintainers and answering this question would be appreciated. @@ -74,29 +74,29 @@ requesting an assignment form from , please cc the libstdc++ maintainer above so that progress can be monitored. -

    Getting Sources

    +

    Getting Sources

    Getting write access (look for "Write after approval") -

    Submitting Patches

    +

    Submitting Patches

    Every patch must have several pieces of information before it can be properly evaluated. Ideally (and to ensure the fastest possible response from the maintainers) it would have all of these pieces: -

    • +

      • A description of the bug and how your patch fixes this bug. For new features a description of the feature and your implementation. -

      • +

      • A ChangeLog entry as plain text; see the various ChangeLog files for format and content. If using you are using emacs as your editor, simply position the insertion point at the beginning of your change and hit CX-4a to bring up the appropriate ChangeLog entry. See--magic! Similar functionality also exists for vi. -

      • +

      • A testsuite submission or sample program that will easily and simply show the existing error or test new functionality. -

      • +

      • The patch itself. If you are accessing the SVN repository use svn update; svn diff NEW; else, use diff -cp OLD NEW ... If your @@ -105,7 +105,7 @@ diff. The SVN Tricks wiki page has information on customising the output of svn diff. -

      • +

      • When you have all these pieces, bundle them up in a mail message and send it to libstdc++@gcc.gnu.org. All patches and related discussion should be sent to the diff --git a/libstdc++-v3/doc/html/manual/appendix_free.html b/libstdc++-v3/doc/html/manual/appendix_free.html index 5b529f93e8e..2431858efd8 100644 --- a/libstdc++-v3/doc/html/manual/appendix_free.html +++ b/libstdc++-v3/doc/html/manual/appendix_free.html @@ -1,11 +1,11 @@ -Appendix C.  Free Software Needs Free Documentation

        Appendix C.  +Appendix C.  Free Software Needs Free Documentation
        Appendix C.  Free Software Needs Free Documentation -
        Prev The GNU C++ Library Next

        Appendix C.  +

        Prev The GNU C++ Library Next

        Appendix C.  Free Software Needs Free Documentation - +

        The biggest deficiency in free operating systems is not in the software--it is the lack of good free manuals that we can include in @@ -120,5 +120,5 @@ that lists free books available from other publishers].

        Copyright © 2004, 2005, 2006, 2007 Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA

        Verbatim copying and distribution of this entire article are permitted worldwide, without royalty, in any medium, provided this notice is preserved.

        Report any problems or suggestions to .

        Prev Up Next
        Backwards Compatibility Home Appendix D.  - GNU General Public License version 3 + GNU General Public License version 3
        diff --git a/libstdc++-v3/doc/html/manual/appendix_gfdl.html b/libstdc++-v3/doc/html/manual/appendix_gfdl.html index cbd35d59e4f..6b6e69ea86d 100644 --- a/libstdc++-v3/doc/html/manual/appendix_gfdl.html +++ b/libstdc++-v3/doc/html/manual/appendix_gfdl.html @@ -1,6 +1,6 @@ -Appendix E. GNU Free Documentation License
        Appendix E. GNU Free Documentation License
        Prev The GNU C++ Library Next

        Appendix E. GNU Free Documentation License

        +Appendix E. GNU Free Documentation License

        Appendix E. GNU Free Documentation License
        Prev The GNU C++ Library Next

        Appendix E. GNU Free Documentation License

        Copyright (C) 2000, 2001, 2002 Free Software Foundation, Inc. 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. Everyone is permitted to copy and @@ -173,36 +173,36 @@ filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: -

        1. +

          1. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. -
          2. +
          3. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. -
          4. +
          5. State on the Title page the name of the publisher of the Modified Version, as the publisher. -
          6. +
          7. Preserve all the copyright notices of the Document. -
          8. +
          9. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. -
          10. +
          11. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. -
          12. +
          13. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. -
          14. +
          15. Include an unaltered copy of this License. -
          16. +
          17. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If @@ -210,7 +210,7 @@ stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. -
          18. +
          19. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was @@ -218,22 +218,22 @@ a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. -
          20. +
          21. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. -
          22. +
          23. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. -
          24. +
          25. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. -
          26. +
          27. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section. -
          28. +
          29. Preserve any Warranty Disclaimers.

          If the Modified Version includes new front-matter sections or appendices @@ -391,5 +391,5 @@ software license, such as the GNU General Public License, to permit their use in free software.

        Prev Up Next
        Appendix D.  - GNU General Public License version 3 + GNU General Public License version 3  Home Index
        diff --git a/libstdc++-v3/doc/html/manual/appendix_gpl.html b/libstdc++-v3/doc/html/manual/appendix_gpl.html index 0f9a838f365..48c1f78e166 100644 --- a/libstdc++-v3/doc/html/manual/appendix_gpl.html +++ b/libstdc++-v3/doc/html/manual/appendix_gpl.html @@ -1,8 +1,8 @@ -Appendix D.  GNU General Public License version 3
        Appendix D.  - GNU General Public License version 3 -
        Prev The GNU C++ Library Next

        Appendix D.  +Appendix D.  GNU General Public License version 3
        Appendix D.  + GNU General Public License version 3 +
        Prev The GNU C++ Library Next

        Appendix D.  GNU General Public License version 3

        Version 3, 29 June 2007 @@ -76,7 +76,7 @@

        The precise terms and conditions for copying, distribution and modification follow. -

        +

        TERMS AND CONDITIONS

        0. Definitions. @@ -219,15 +219,15 @@ You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: -

        1. +

          1. The work must carry prominent notices stating that you modified it, and giving a relevant date. -

          2. +

          3. The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”. -

          4. +

          5. You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the @@ -235,7 +235,7 @@ packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. -

          6. +

          7. If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need @@ -255,12 +255,12 @@ You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways: -

            1. +

              1. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange. -

              2. +

              3. Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts @@ -271,12 +271,12 @@ price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge. -

              4. +

              5. Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b. -

              6. +

              7. Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no @@ -289,7 +289,7 @@ Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements. -

              8. +

              9. Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under @@ -366,24 +366,24 @@ Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms: -

                1. +

                  1. Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or -

                  2. +

                  3. Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or -

                  4. +

                  5. Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or -

                  6. +

                  7. Limiting the use for publicity purposes of names of licensors or authors of the material; or -

                  8. +

                  9. Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or -

                  10. +

                  11. Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any @@ -617,7 +617,7 @@ waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee. -

                    +

                    END OF TERMS AND CONDITIONS

                    How to Apply These Terms to Your New Programs diff --git a/libstdc++-v3/doc/html/manual/appendix_porting.html b/libstdc++-v3/doc/html/manual/appendix_porting.html index 037759421ee..842b335d7de 100644 --- a/libstdc++-v3/doc/html/manual/appendix_porting.html +++ b/libstdc++-v3/doc/html/manual/appendix_porting.html @@ -1,12 +1,12 @@ -Appendix B.  Porting and Maintenance
                    Appendix B.  +Appendix B.  Porting and Maintenance
                    Appendix B.  Porting and Maintenance -
                    Prev The GNU C++ Library Next

                    Appendix B.  +

                    Prev The GNU C++ Library Next

                    Appendix B.  Porting and Maintenance - -

                    Table of Contents

                    Configure and Build Hacking
                    Prerequisites
                    Overview: What Comes from Where
                    Storing Information in non-AC files (like configure.host)
                    Coding and Commenting Conventions
                    The acinclude.m4 layout
                    GLIBCXX_ENABLE, the --enable maker
                    Porting to New Hardware or Operating Systems
                    Operating System
                    CPU
                    Character Types
                    Thread Safety
                    Numeric Limits
                    Libtool
                    Test
                    Organization
                    Running the Testsuite
                    Writing a new test case
                    Test Harness and Utilities
                    ABI Policy and Guidelines
                    The C++ Interface
                    Versioning
                    Allowed Changes
                    Prohibited Changes
                    Implementation
                    Testing
                    Outstanding Issues
                    API Evolution and Deprecation History
                    3.0
                    3.1
                    3.2
                    3.3
                    3.4
                    4.0
                    4.1
                    4.2
                    4.3
                    Backwards Compatibility
                    First
                    Second
                    Third

                    Configure and Build Hacking

                    Prerequisites

                    + +

              Table of Contents

              Configure and Build Hacking
              Prerequisites
              Overview: What Comes from Where
              Storing Information in non-AC files (like configure.host)
              Coding and Commenting Conventions
              The acinclude.m4 layout
              GLIBCXX_ENABLE, the --enable maker
              Porting to New Hardware or Operating Systems
              Operating System
              CPU
              Character Types
              Thread Safety
              Numeric Limits
              Libtool
              Test
              Organization
              Running the Testsuite
              Writing a new test case
              Test Harness and Utilities
              Special Topics
              ABI Policy and Guidelines
              The C++ Interface
              Versioning
              Allowed Changes
              Prohibited Changes
              Implementation
              Testing
              Outstanding Issues
              API Evolution and Deprecation History
              3.0
              3.1
              3.2
              3.3
              3.4
              4.0
              4.1
              4.2
              4.3
              4.4
              4.5
              Backwards Compatibility
              First
              Second
              Third

              Configure and Build Hacking

              Prerequisites

              As noted previously, certain other tools are necessary for hacking on files that control configure (configure.ac, @@ -17,7 +17,7 @@ in GCC try to stay in sync with each other in terms of versions of the auto-tools used, so please try to play nicely with the neighbors. -

              Overview: What Comes from Where

              +

              Overview: What Comes from Where

                 Dependency Graph Configure to Build Files

              Regenerate all generated files by using the command sequence @@ -29,7 +29,7 @@ the current requirements and your vendor's choice of installation names. -

              Storing Information in non-AC files (like configure.host)

              +

              Storing Information in non-AC files (like configure.host)

              Until that glorious day when we can use AC_TRY_LINK with a cross-compiler, we have to hardcode the results of what the tests would have shown if they could be run. So we have an inflexible @@ -51,7 +51,7 @@ for instance, but then we would need arguments to aclocal/autoconf to properly find them all when generating configure. I would discourage that. -

              Coding and Commenting Conventions

              +

              Coding and Commenting Conventions

              Most comments should use {octothorpes, shibboleths, hash marks, pound signs, whatever} rather than "dnl". Nearly all comments in configure.ac should. Comments inside macros written in ancilliary @@ -68,7 +68,7 @@ Do not use any $target* variables, such as $target_alias. The single exception is in configure.ac, for automake+dejagnu's sake. -

              The acinclude.m4 layout

              +

              The acinclude.m4 layout

              The nice thing about acinclude.m4/aclocal.m4 is that macros aren't actually performed/called/expanded/whatever here, just loaded. So we can arrange the contents however we like. As of this writing, @@ -139,14 +139,14 @@

              Things which we don't seem to use directly, but just has to be present otherwise stuff magically goes wonky. -

              GLIBCXX_ENABLE, the --enable maker

              +

              GLIBCXX_ENABLE, the --enable maker

              All the GLIBCXX_ENABLE_FOO macros use a common helper, GLIBCXX_ENABLE. (You don't have to use it, but it's easy.) The helper does two things for us: -

              1. +

                1. Builds the call to the AC_ARG_ENABLE macro, with --help text properly quoted and aligned. (Death to changequote!) -

                2. +

                3. Checks the result against a list of allowed possibilities, and signals a fatal error if there's no match. This means that the rest of the GLIBCXX_ENABLE_FOO macro doesn't need to test for @@ -168,13 +168,13 @@ GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING) GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, permit a|b|c) GLIBCXX_ENABLE (FEATURE, DEFAULT, HELP-ARG, HELP-STRING, SHELL-CODE-HANDLER) -

                  • +

                    • FEATURE is the string that follows --enable. The results of the test (such as it is) will be in the variable $enable_FEATURE, where FEATURE has been squashed. Example: [extra-foo], controlled by the --enable-extra-foo option and stored in $enable_extra_foo. -

                    • +

                    • DEFAULT is the value to store in $enable_FEATURE if the user does not pass --enable/--disable. It should be one of the permitted values passed later. Examples: [yes], or @@ -185,7 +185,7 @@ For cases where we need to probe for particular models of things, it is useful to have an undocumented "auto" value here (see GLIBCXX_ENABLE_CLOCALE for an example). -

                    • +

                    • HELP-ARG is any text to append to the option string itself in the --help output. Examples: [] (i.e., an empty string, which appends nothing), [=BAR], which produces @@ -198,7 +198,7 @@ that's how you embed autoconf special characters in output text. They're called quadrigraphs and you should use them whenever necessary. -

                    • HELP-STRING is what you think it is. Do not include the +

                    • HELP-STRING is what you think it is. Do not include the "default" text like we used to do; it will be done for you by GLIBCXX_ENABLE. By convention, these are not full English sentences. Example: [turn on extra foo] diff --git a/libstdc++-v3/doc/html/manual/associative.html b/libstdc++-v3/doc/html/manual/associative.html index c68cf1e0280..06a9de6aa3a 100644 --- a/libstdc++-v3/doc/html/manual/associative.html +++ b/libstdc++-v3/doc/html/manual/associative.html @@ -1,18 +1,18 @@ -Chapter 17. Associative

                      Chapter 17. Associative
                      Prev Part VII.  +Chapter 17. Associative
                      Chapter 17. Associative
                      Prev Part VII.  Containers - Next

                      Chapter 17. Associative

                      Table of Contents

                      Insertion Hints
                      bitset
                      Size Variable
                      Type String

                      Insertion Hints

                      +

                      		 Next

                      Chapter 17. Associative

                      Table of Contents

                      Insertion Hints
                      bitset
                      Size Variable
                      Type String

                      Insertion Hints

                      Section [23.1.2], Table 69, of the C++ standard lists this function for all of the associative containers (map, set, etc): 

                             a.insert(p,t);

                      where 'p' is an iterator into the container 'a', and 't' is the - item to insert. The standard says that “t is + item to insert. The standard says that “t is inserted as close as possible to the position just prior to - p.” (Library DR #233 addresses this topic, + p.” (Library DR #233 addresses this topic, referring to N1780. Since version 4.2 GCC implements the resolution to DR 233, so that insertions happen as close as possible to the hint. For @@ -31,25 +31,25 @@ than and less than refer to the results of the strict weak ordering imposed on the container by its comparison object, which defaults to (basically) - “<”. Using those phrases is semantically sloppy, + “<”. Using those phrases is semantically sloppy, but I didn't want to get bogged down in syntax. I assume that if you are intelligent enough to use your own comparison objects, - you are also intelligent enough to assign “greater” - and “lesser” their new meanings in the next + you are also intelligent enough to assign “greater” + and “lesser” their new meanings in the next paragraph. *grin*

                      If the hint parameter ('p' above) is equivalent to: -

                      • +

                        • begin(), then the item being inserted should have a key less than all the other keys in the container. The item will be inserted at the beginning of the container, becoming the new entry at begin(). -

                        • +

                        • end(), then the item being inserted should have a key greater than all the other keys in the container. The item will be inserted at the end of the container, becoming the new entry at end(). -

                        • +

                        • neither begin() nor end(), then: Let h be the entry in the container pointed to by hint, that is, h = *hint. Then @@ -59,10 +59,10 @@ h and h's predecessor.

                        For multimap and multiset, the - restrictions are slightly looser: “greater than” - should be replaced by “not less than”and “less - than” should be replaced by “not greater - than.” (Why not replace greater with + restrictions are slightly looser: “greater than” + should be replaced by “not less than”and “less + than” should be replaced by “not greater + than.” (Why not replace greater with greater-than-or-equal-to? You probably could in your head, but the mathematicians will tell you that it isn't the same thing.)

                        diff --git a/libstdc++-v3/doc/html/manual/auto_ptr.html b/libstdc++-v3/doc/html/manual/auto_ptr.html index 88b3397b419..777264504bf 100644 --- a/libstdc++-v3/doc/html/manual/auto_ptr.html +++ b/libstdc++-v3/doc/html/manual/auto_ptr.html @@ -1,6 +1,6 @@ -auto_ptr

                        auto_ptr
                        Prev Chapter 11. Memory Next

                        auto_ptr

                        Limitations

                        Explaining all of the fun and delicious things that can +auto_ptr

                        auto_ptr
                        Prev Chapter 11. Memory Next

                        auto_ptr

                        Limitations

                        Explaining all of the fun and delicious things that can happen with misuse of the auto_ptr class template (called AP here) would take some time. Suffice it to say that the use of AP @@ -51,7 +51,7 @@ to die. AP is trivial to write, however, so you could write your own auto_array_ptr for that situation (in fact, this has been done many times; check the mailing lists, Usenet, Boost, etc). -

                        Use in Containers

                        +

                        Use in Containers

                        All of the containers described in the standard library require their contained types to have, among other things, a copy constructor like this: @@ -70,7 +70,7 @@

                        The resulting rule is simple: Never ever use a container of auto_ptr objects. The standard says that - “undefined” behavior is the result, but it is + “undefined” behavior is the result, but it is guaranteed to be messy.

                        To prevent you from doing this to yourself, the diff --git a/libstdc++-v3/doc/html/manual/backwards.html b/libstdc++-v3/doc/html/manual/backwards.html index 252d177d4aa..39b9d3880c5 100644 --- a/libstdc++-v3/doc/html/manual/backwards.html +++ b/libstdc++-v3/doc/html/manual/backwards.html @@ -1,9 +1,9 @@ -Backwards Compatibility

                        Backwards Compatibility
                        Prev Appendix B.  +Backwards Compatibility
                        Backwards Compatibility
                        Prev Appendix B.  Porting and Maintenance - Next

                        Backwards Compatibility

                        First

                        The first generation GNU C++ library was called libg++. It was a +

                        		 Next

                        Backwards Compatibility

                        First

                        The first generation GNU C++ library was called libg++. It was a separate GNU project, although reliably paired with GCC. Rumors imply that it had a working relationship with at least two kinds of dinosaur. @@ -16,9 +16,9 @@ now and are well-supported, whereas genclass (mostly) predates them.) ISO Standard (e.g., statistical analysis). While there are a lot of really useful things that are used by a lot of people, the Standards Committee couldn't include everything, and so a lot of those -“obvious” classes didn't get included. -

                        Known Issues include many of the limitations of its immediate ancestor.

                        Portability notes and known implementation limitations are as follows.

                        No ios_base

                        At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit. -

                        No cout in ostream.h, no cin in istream.h

                        +“obvious” classes didn't get included. +

                        Known Issues include many of the limitations of its immediate ancestor.

                        Portability notes and known implementation limitations are as follows.

                        No ios_base

                        At least some older implementations don't have std::ios_base, so you should use std::ios::badbit, std::ios::failbit and std::ios::eofbit and std::ios::goodbit. +

                        No cout in ostream.h, no cin in istream.h

                        In earlier versions of the standard, fstream.h, ostream.h @@ -32,7 +32,7 @@ archived. For the desperate, the GCC extensions page describes where to find the last libg++ source. The code is considered replaced and rewritten. -

                        Second

                        +

                        Second

                        The second generation GNU C++ library was called libstdc++, or libstdc++-v2. It spans the time between libg++ and pre-ISO C++ standardization and is usually associated with the following GCC @@ -44,7 +44,7 @@ considered replaced and rewritten. archived. The code is considered replaced and rewritten.

                        Portability notes and known implementation limitations are as follows. -

                        Namespace std:: not supported

                        +

                        Namespace std:: not supported

                        Some care is required to support C++ compiler and or library implementation that do not have the standard library in namespace std. @@ -74,7 +74,7 @@ considered replaced and rewritten.

                        Another pre-processor based approach is to define a macro NAMESPACE_STD, which is defined to either - “ ” or “std” based on a compile-type + “ ” or “std” based on a compile-type test. On GNU systems, this can be done with autotools by means of an autoconf test (see below) for HAVE_NAMESPACE_STD, then using that to set a value for the NAMESPACE_STD @@ -108,20 +108,20 @@ AC_DEFUN([AC_CXX_NAMESPACE_STD], [ AC_DEFINE(HAVE_NAMESPACE_STD,,[Define if g++ supports namespace std. ]) fi ]) -

                        Illegal iterator usage

                        +

                        Illegal iterator usage

                        The following illustrate implementation-allowed illegal iterator use, and then correct use. -

                        • +

                          • you cannot do ostream::operator<<(iterator) to print the address of the iterator => use operator<< &*iterator instead -

                          • +

                          • you cannot clear an iterator's reference (iterator = 0) => use iterator = iterator_type(); -

                          • +

                          • if (iterator) won't work any more => use if (iterator != iterator_type()) -

                        isspace from cctype is a macro +

                      isspace from cctype is a macro

                      Glibc 2.0.x and 2.1.x define ctype.h functionality as macros (isspace, isalpha etc.). @@ -154,7 +154,7 @@ std:: (__ctype_b[(int) ( ( 'X' ) )] & (unsigned short int) _ISspace ) ; (ctype.h) and the definitions in namespace std:: (<cctype>). -

                      No vector::at, deque::at, string::at

                      +

                      No vector::at, deque::at, string::at

                      One solution is to add an autoconf-test for this: 

                       AC_MSG_CHECKING(for container::at)
@@ -171,7 +171,7 @@ deque<int> test_deque(3);
 test_deque.at(2);
 vector<int> test_vector(2);
 test_vector.at(1);
-string test_string(“test_string”);
+string test_string(“test_string”);
 test_string.at(3);
 ],
 [AC_MSG_RESULT(yes)
@@ -180,7 +180,7 @@ AC_DEFINE(HAVE_CONTAINER_AT)],

                      If you are using other (non-GNU) compilers it might be a good idea to check for string::at separately. -

                      No std::char_traits<char>::eof

                      +

                      No std::char_traits<char>::eof

                      Use some kind of autoconf test, plus this: 

                       #ifdef HAVE_CHAR_TRAITS
@@ -188,7 +188,7 @@ AC_DEFINE(HAVE_CONTAINER_AT)],
 #else
 #define CPP_EOF EOF
 #endif
-

                      No string::clear

                      +

                      No string::clear

                      There are two functions for deleting the contents of a string: clear and erase (the latter returns the string). @@ -206,25 +206,25 @@ erase(size_type __pos = 0, size_type __n = npos) Unfortunately, clear is not implemented in this version, so you should use erase (which is probably faster than operator=(charT*)). -

                      +

                      Removal of ostream::form and istream::scan extensions

                      These are no longer supported. Please use stringstreams instead. -

                      No basic_stringbuf, basic_stringstream

                      +

                      No basic_stringbuf, basic_stringstream

                      Although the ISO standard i/ostringstream-classes are provided, (sstream), for compatibility with older implementations the pre-ISO i/ostrstream (strstream) interface is also provided, with these caveats: -

                      • +

                        • strstream is considered to be deprecated -

                        • +

                        • strstream is limited to char -

                        • +

                        • with ostringstream you don't have to take care of terminating the string or freeing its memory -

                        • +

                        • istringstream can be re-filled (clear(); str(input);)

                        @@ -242,7 +242,7 @@ erase(size_type __pos = 0, size_type __n = npos) std::ostrstream oss; #endif -oss << “Name=” << m_name << “, number=” << m_number << std::endl; +oss << “Name=” << m_name << “, number=” << m_number << std::endl; ... #ifndef HAVE_SSTREAM oss << std::ends; // terminate the char*-string @@ -298,15 +298,15 @@ any = temp;

                        Another example of using stringstreams is in this howto.

                        There is additional information in the libstdc++-v2 info files, in -particular “info iostream”. -

                      Little or no wide character support

                      +particular “info iostream”. +

                      Little or no wide character support

                      Classes wstring and char_traits<wchar_t> are not supported. -

                      No templatized iostreams

                      +

                      No templatized iostreams

                      Classes wfilebuf and wstringstream are not supported. -

                      Thread safety issues

                      +

                      Thread safety issues

                      Earlier GCC releases had a somewhat different approach to threading configuration and proper compilation. Before GCC 3.0, configuration of the threading model was dictated by compiler @@ -342,11 +342,11 @@ particular “info iostream”. first relevant message in the thread; from there you can use "Thread Next" to move down the thread. This farm is in latest-to-oldest order. -

                      • +

                        • Our threading expert Loren gives a breakdown of the six situations involving threads for the 3.0 release series. -

                        • +

                        • This message inspired a recent updating of issues with threading and the SGI STL library. It also contains some @@ -357,14 +357,14 @@ particular “info iostream”. few people with access to the backup tapes have been too swamped with work to restore them. Many of the points have been superseded anyhow.) -

                      Third

                      The third generation GNU C++ library is called libstdc++, or +

                      Third

                      The third generation GNU C++ library is called libstdc++, or libstdc++-v3.

                      The subset commonly known as the Standard Template Library (chapters 23 through 25, mostly) is adapted from the final release of the SGI STL (version 3.3), with extensive changes.

                      A more formal description of the V3 goals can be found in the official design document. -

                      Portability notes and known implementation limitations are as follows.

                      Pre-ISO headers moved to backwards or removed

                      The pre-ISO C++ headers +

                      Portability notes and known implementation limitations are as follows.

                      Pre-ISO headers moved to backwards or removed

                      The pre-ISO C++ headers (iostream.h, defalloc.h etc.) are available, unlike previous libstdc++ versions, but inclusion generates a warning that you are using deprecated headers. @@ -436,7 +436,7 @@ like vector.h can be replaced with using namespace std; can be put at the global scope. This should be enough to get this code compiling, assuming the other usage is correct. -

                      Extension headers hash_map, hash_set moved to ext or backwards

                      At this time most of the features of the SGI STL extension have been +

                      Extension headers hash_map, hash_set moved to ext or backwards

                      At this time most of the features of the SGI STL extension have been replaced by standardized libraries. In particular, the unordered_map and unordered_set containers of TR1 are suitable replacement for the non-standard hash_map and hash_set @@ -508,18 +508,18 @@ AC_DEFUN([AC_HEADER_EXT_HASH_SET], [ AC_DEFINE(HAVE_EXT_HASH_SET,,[Define if ext/hash_set is present. ]) fi ]) -

                      No ios::nocreate/ios::noreplace. +

                      No ios::nocreate/ios::noreplace.

                      The existence of ios::nocreate being used for input-streams has been confirmed, most probably because the author thought it would be more correct to specify nocreate explicitly. So it can be left out for input-streams. -

                      For output streams, “nocreate” is probably the default, +

                      For output streams, “nocreate” is probably the default, unless you specify std::ios::trunc ? To be safe, you can open the file for reading, check if it has been opened, and then decide whether you want to create/replace or not. To my knowledge, even older implementations support app, ate and trunc (except for app ?). -

                      +

                      No stream::attach(int fd)

                      Phil Edwards writes: It was considered and rejected for the ISO @@ -542,7 +542,7 @@ No stream::attach(int fd) For another example of this, refer to fdstream example by Nicolai Josuttis. -

                      +

                      Support for C++98 dialect.

                      Check for complete library coverage of the C++1998/2003 standard. 

                      @@ -610,7 +610,7 @@ AC_DEFUN([AC_HEADER_STDCXX_98], [
     AC_DEFINE(STDCXX_98_HEADERS,,[Define if ISO C++ 1998 header files are present. ])
   fi
 ])
-

                      +

                      Support for C++TR1 dialect.

                      Check for library coverage of the TR1 standard. 

                      @@ -687,7 +687,7 @@ AC_DEFUN([AC_HEADER_TR1_UNORDERED_SET], [
     AC_DEFINE(HAVE_TR1_UNORDERED_SET,,[Define if tr1/unordered_set is present. ])
   fi
 ])
-

                      +

                      Support for C++0x dialect.

                      Check for baseline language coverage in the compiler for the C++0xstandard. 

                      @@ -899,27 +899,27 @@ AC_DEFUN([AC_HEADER_UNORDERED_SET], [
     AC_DEFINE(HAVE_UNORDERED_SET,,[Define if unordered_set is present. ])
   fi
 ])
-

                      +

                      Container::iterator_type is not necessarily Container::value_type*

                      This is a change in behavior from the previous version. Now, most iterator_type typedefs in container classes are POD objects, not value_type pointers. -

                      Bibliography

                      [ +

                      Bibliography

                      [ kegel41 ] Migrating to GCC 4.1 . Dan Kegel. - .

                      [ + .

                      [ kegel41 ] Building the Whole Debian Archive with GCC 4.1: A Summary . Martin Michlmayr. - .

                      [ + .

                      [ lbl32 ] Migration guide for GCC-3.2 diff --git a/libstdc++-v3/doc/html/manual/bitmap_allocator.html b/libstdc++-v3/doc/html/manual/bitmap_allocator.html index 806ca047865..4a9f0405df7 100644 --- a/libstdc++-v3/doc/html/manual/bitmap_allocator.html +++ b/libstdc++-v3/doc/html/manual/bitmap_allocator.html @@ -1,7 +1,7 @@ -bitmap_allocator

                      bitmap_allocator
                      Prev Chapter 33. Allocators Next

                      bitmap_allocator

                      -

                      Design

                      +bitmap_allocator

                      bitmap_allocator
                      Prev Chapter 33. Allocators Next

                      bitmap_allocator

                      +

                      Design

                      As this name suggests, this allocator uses a bit-map to keep track of the used and unused memory locations for it's book-keeping purposes. @@ -27,7 +27,7 @@ Mutex Protection around every allocation/deallocation. The state of the macro is picked up automatically from the gthr abstraction layer. -

                      Implementation

                      Free List Store

                      +

                      Implementation

                      Free List Store

                      The Free List Store (referred to as FLS for the remaining part of this document) is the Global memory pool that is shared by all instances of the bitmapped allocator instantiated for any type. This maintains a @@ -65,17 +65,17 @@ this internal fragmentation has to be decided by this function. I can see 3 possibilities right now. Please add more as and when you find better strategies. -

                      1. Equal size check. Return true only when the 2 blocks are of equal -size.

                      2. Difference Threshold: Return true only when the _block_size is +

                        1. Equal size check. Return true only when the 2 blocks are of equal +size.

                        2. Difference Threshold: Return true only when the _block_size is greater than or equal to the _required_size, and if the _BS is > _RS by a difference of less than some THRESHOLD value, then return true, -else return false.

                        3. Percentage Threshold. Return true only when the _block_size is +else return false.

                        4. Percentage Threshold. Return true only when the _block_size is greater than or equal to the _required_size, and if the _BS is > _RS by a percentage of less than some THRESHOLD value, then return true, else return false.

                        Currently, (3) is being used with a value of 36% Maximum wastage per Super Block. -

                      Super Block

                      +

                      Super Block

                      A super block is the block of memory acquired from the FLS from which the bitmap allocator carves out memory for single objects and satisfies the user's requests. These super blocks come in @@ -90,7 +90,7 @@ else return false.

                The super block is contained in the FLS, and the FLS is responsible for getting / returning Super Bocks to and from the OS using operator new as defined by the C++ standard. -

              Super Block Data Layout

              +

              Super Block Data Layout

              Each Super Block will be of some size that is a multiple of the number of Bits Per Block. Typically, this value is chosen as Bits_Per_Byte x sizeof(size_t). On an x86 system, this gives the @@ -103,7 +103,7 @@ else return false.

            Consider a block of size 64 ints. In memory, it would look like this: (assume a 32-bit system where, size_t is a 32-bit entity). -

            Table 33.1. Bitmap Allocator Memory Map

            268042949672954294967295Data -> Space for 64 ints

            +

            Table 33.1. Bitmap Allocator Memory Map

            268042949672954294967295Data -> Space for 64 ints

            The first Column(268) represents the size of the Block in bytes as seen by the Bitmap Allocator. Internally, a global free list is used to keep track of the free blocks used and given back by the @@ -130,7 +130,7 @@ else return false.

          The 3rd 4x2 is size of the bitmap itself, which is the size of 32-bits x 2, which is 8-bytes, or 2 x sizeof(size_t). -

        Maximum Wasted Percentage

        +

        Maximum Wasted Percentage

        This has nothing to do with the algorithm per-se, only with some vales that must be chosen correctly to ensure that the allocator performs well in a real word scenario, and maintains a good @@ -155,29 +155,29 @@ For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524%

        Thus, knowing these values, and based on the sizeof(value_type), we may create a function that returns the Max_Wastage_Percentage for us to use. -

        allocate

        +

        allocate

        The allocate function is specialized for single object allocation ONLY. Thus, ONLY if n == 1, will the bitmap_allocator's specialized algorithm be used. Otherwise, the request is satisfied directly by calling operator new.

        Suppose n == 1, then the allocator does the following: -

        1. +

          1. Checks to see whether a free block exists somewhere in a region of memory close to the last satisfied request. If so, then that block is marked as allocated in the bit map and given to the user. If not, then (2) is executed. -

          2. +

          3. Is there a free block anywhere after the current block right up to the end of the memory that we have? If so, that block is found, and the same procedure is applied as above, and returned to the user. If not, then (3) is executed. -

          4. +

          5. Is there any block in whatever region of memory that we own free? This is done by checking -

            • +

              • The use count for each super block, and if that fails then -

              • +

              • The individual bit-maps for each super block.

              Note: Here we are never touching any of the memory that the @@ -186,21 +186,21 @@ For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524% misses. If this succeeds then we apply the same procedure on that bit-map as (1), and return that block of memory to the user. However, if this process fails, then we resort to (4). -

            • +

            • This process involves Refilling the internal exponentially growing memory pool. The said effect is achieved by calling _S_refill_pool which does the following: -

              • +

                • Gets more memory from the Global Free List of the Required size. -

                • +

                • Adjusts the size for the next call to itself. -

                • +

                • Writes the appropriate headers in the bit-maps. -

                • +

                • Sets the use count for that super-block just allocated to 0 (zero). -

                • +

                • All of the above accounts to maintaining the basic invariant for the allocator. If the invariant is maintained, we are sure that all is well. Now, the same process is applied on @@ -210,13 +210,13 @@ For map/multimap: k = 12, and c = 4 (int and double), we get: 37.524% Thus, you can clearly see that the allocate function is nothing but a combination of the next-fit and first-fit algorithm optimized ONLY for single object allocations. -

                deallocate

                +

                deallocate

                The deallocate function again is specialized for single objects ONLY. For all n belonging to > 1, the operator delete is called without further ado, and the deallocate function returns.

                However for n == 1, a series of steps are performed: -

                1. +

                  1. We first need to locate that super-block which holds the memory location given to us by the user. For that purpose, we maintain a static variable _S_last_dealloc_index, which holds the index @@ -227,7 +227,7 @@ single object allocations. the check for belongs_to succeeds, then we determine the bit-map for the given pointer, and locate the index into that bit-map, and mark that bit as free by setting it. -

                  2. +

                  3. If the _S_last_dealloc_index does not point to the memory block that we're looking for, then we do a linear search on the block stored in the vector of Block Pairs. This vector in code is @@ -241,7 +241,7 @@ single object allocations. the vector. While doing this, we also make sure that the basic invariant is maintained by making sure that _S_last_request and _S_last_dealloc_index point to valid locations within the vector. -

                  Questions

                  1

                  +

                  Questions

                  1

                  Q1) The "Data Layout" section is cryptic. I have no idea of what you are trying to say. Layout of what? The free-list? Each bitmap? The Super Block? @@ -251,7 +251,7 @@ size. In the example, a super block of size 32 x 1 is taken. The general formula for calculating the size of a super block is 32 x sizeof(value_type) x 2^n, where n ranges from 0 to 32 for 32-bit systems. -

                  2

                  +

                  2

                  And since I just mentioned the term `each bitmap', what in the world is meant by it? What does each bitmap manage? How does it relate to the super block? Is the Super @@ -268,7 +268,7 @@ Block a bitmap as well? blocks' status. Each bit-map is made up of a number of size_t, whose exact number for a super-block of a given size I have just mentioned. -

                  3

                  +

                  3

                  How do the allocate and deallocate functions work in regard to bitmaps?

                  @@ -297,15 +297,15 @@ Block a bitmap as well?

                  The bit-map now looks like this: 1111111111111111111111111111111111111111111111111111111111111110 -

                  Locality

                  +

                  Locality

                  Another issue would be whether to keep the all bitmaps in a separate area in memory, or to keep them near the actual blocks that will be given out or allocated for the client. After some testing, I've decided to keep these bitmaps close to the actual blocks. This will help in 2 ways. -

                  1. Constant time access for the bitmap themselves, since no kind of +

                    1. Constant time access for the bitmap themselves, since no kind of look up will be needed to find the correct bitmap list or it's -equivalent.

                    2. And also this would preserve the cache as far as possible.

                    +equivalent.

                  2. And also this would preserve the cache as far as possible.

                  So in effect, this kind of an allocator might prove beneficial from a purely cache point of view. But this allocator has been made to try and roll out the defects of the node_allocator, wherein the nodes get @@ -314,7 +314,7 @@ equivalent.

                2. And also this would preserve the cache as far as poss new_allocator's book keeping overhead is too much for small objects and single object allocations, though it preserves the locality of blocks very well when they are returned back to the allocator. -

                Overhead and Grow Policy

                +

                Overhead and Grow Policy

                Expected overhead per block would be 1 bit in memory. Also, once the address of the free list has been found, the cost for allocation/deallocation would be negligible, and is supposed to be diff --git a/libstdc++-v3/doc/html/manual/bitset.html b/libstdc++-v3/doc/html/manual/bitset.html index acc150df7e8..9cff276218f 100644 --- a/libstdc++-v3/doc/html/manual/bitset.html +++ b/libstdc++-v3/doc/html/manual/bitset.html @@ -1,6 +1,6 @@ -bitset

                bitset
                Prev Chapter 17. Associative Next

                bitset

                Size Variable

                +bitset

                bitset
                Prev Chapter 17. Associative Next

                bitset

                Size Variable

                No, you cannot write code of the form 

                       #include <bitset>
@@ -18,7 +18,7 @@
      There are a couple of ways to handle this kind of thing.  Please
      consider all of them before passing judgement.  They include, in
      no particular order:
-   
                • A very large N in bitset<N>.
                • A container<bool>.
                • Extremely weird solutions.
                
+   
                • A very large N in bitset<N>.
                • A container<bool>.
                • Extremely weird solutions.
                
      A very large N in
      bitset<N>.   It has been
      pointed out a few times in newsgroups that N bits only takes up
@@ -28,10 +28,10 @@
      housekeeping info; it is known at compile time exactly how large
      the set is) will hold over four million bits.  If you're using
      those bits as status flags (e.g.,
-     “changed”/“unchanged” flags), that's a
+     “changed”/“unchanged” flags), that's a
      lot of state.
    
                
-     You can then keep track of the “maximum bit used”
+     You can then keep track of the “maximum bit used”
      during some testing runs on representative data, make note of how
      many of those bits really need to be there, and then reduce N to
      a smaller number.  Leave some extra space, of course.  (If you
@@ -85,21 +85,21 @@
    
                
      Also note that the implementation of bitset used in libstdc++ has
      some extensions.
-

                Type String

                +

                Type String

                Bitmasks do not take char* nor const char* arguments in their constructors. This is something of an accident, but you can read - about the problem: follow the library's “Links” from - the homepage, and from the C++ information “defect - reflector” link, select the library issues list. Issue + about the problem: follow the library's “Links” from + the homepage, and from the C++ information “defect + reflector” link, select the library issues list. Issue number 116 describes the problem.

                For now you can simply make a temporary string object using the constructor expression: 

                -      std::bitset<5> b ( std::string(“10110”) );
+      std::bitset<5> b ( std::string(“10110”) );

                instead of 

                -      std::bitset<5> b ( “10110” );    // invalid
+      std::bitset<5> b ( “10110” );    // invalid
                Prev Up Next
                Chapter 17. Associative Home Chapter 18. Interacting with C
                diff --git a/libstdc++-v3/doc/html/manual/bk01ix01.html b/libstdc++-v3/doc/html/manual/bk01ix01.html index 51a67bbe12d..576c0d4f7e3 100644 --- a/libstdc++-v3/doc/html/manual/bk01ix01.html +++ b/libstdc++-v3/doc/html/manual/bk01ix01.html @@ -1,6 +1,6 @@ -Index
                Index
                Prev The GNU C++ Library Next

                Index

                A

                Algorithms, +Index
                Index
                Prev The GNU C++ Library Next

                Index

                A

                Algorithms, Algorithms
                Appendix
                Contributing, @@ -42,7 +42,10 @@
                Support, Support -

                U

                Utilities, +

                T

                Test
                Exception Safety, + Qualifying Exception Safety Guarantees + +

                U

                Utilities, Utilities
                Prev Up Next
                Appendix E. GNU Free Documentation License Home 
                diff --git a/libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html b/libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html index 9f1265610be..0ed5fa86fa4 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt02ch04s02.html @@ -1,6 +1,6 @@ -Numeric Properties
                Numeric Properties
                Prev Chapter 4. Types Next

                Numeric Properties

                +Numeric Properties

                Numeric Properties
                Prev Chapter 4. Types Next

                Numeric Properties

                The header limits defines traits classes to give access to various implementation defined-aspects of the fundamental types. The traits classes -- diff --git a/libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html b/libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html index 96825362179..c9225c8b9ca 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt02ch04s03.html @@ -1,6 +1,6 @@ -NULL

                NULL
                Prev Chapter 4. Types Next

                NULL

                +NULL

                NULL
                Prev Chapter 4. Types Next

                NULL

                The only change that might affect people is the type of NULL: while it is required to be a macro, the definition of that macro is not allowed @@ -12,7 +12,7 @@ g++.

                The biggest problem of #defining NULL to be - something like “0L” is that the compiler will view + something like “0L” is that the compiler will view that as a long integer before it views it as a pointer, so overloading won't do what you expect. (This is why g++ has a magic extension, so that diff --git a/libstdc++-v3/doc/html/manual/bk01pt02pr01.html b/libstdc++-v3/doc/html/manual/bk01pt02pr01.html index 4ec01fefd93..80b42c631ec 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt02pr01.html +++ b/libstdc++-v3/doc/html/manual/bk01pt02pr01.html @@ -1,9 +1,9 @@ -

                Prev Part II.  +
                Prev Part II.  Support - Next

                +

                		 Next

                This part deals with the functions called and objects created automatically during the course of a program's existence.

                diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html b/libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html index d72d23d2d95..54df29a6553 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch07s02.html @@ -1,6 +1,6 @@ -Adding Data to Exceptions

                Adding Data to Exceptions
                Prev Chapter 7. Exceptions Next

                Adding Data to Exceptions

                +Adding Data to Exceptions

                Adding Data to Exceptions
                Prev Chapter 7. Exceptions Next

                Adding Data to Exceptions

                The standard exception classes carry with them a single string as data (usually describing what went wrong or where the 'throw' took place). It's good to remember that you can add your own data to diff --git a/libstdc++-v3/doc/html/manual/bk01pt03ch08.html b/libstdc++-v3/doc/html/manual/bk01pt03ch08.html index 5c6d0c83a24..b66b555a2da 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt03ch08.html +++ b/libstdc++-v3/doc/html/manual/bk01pt03ch08.html @@ -1,10 +1,10 @@ -Chapter 8. Concept Checking

                Chapter 8. Concept Checking
                Prev Part III.  +Chapter 8. Concept Checking
                Chapter 8. Concept Checking
                Prev Part III.  Diagnostics - Next

                Chapter 8. Concept Checking

                - In 1999, SGI added “concept checkers” to their +

                		 Next

                Chapter 8. Concept Checking

                + In 1999, SGI added “concept checkers” to their implementation of the STL: code which checked the template parameters of instantiated pieces of the STL, in order to insure that the parameters being used met the requirements of the diff --git a/libstdc++-v3/doc/html/manual/bk01pt05ch13.html b/libstdc++-v3/doc/html/manual/bk01pt05ch13.html index 48fb471b929..e86d7fe1779 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt05ch13.html +++ b/libstdc++-v3/doc/html/manual/bk01pt05ch13.html @@ -1,9 +1,9 @@ -Chapter 13. String Classes

                Chapter 13. String Classes
                Prev Part V.  +Chapter 13. String Classes
                Chapter 13. String Classes
                Prev Part V.  Strings - Next

                Chapter 13. String Classes

                Table of Contents

                Simple Transformations
                Case Sensitivity
                Arbitrary Character Types
                Tokenizing
                Shrink to Fit
                CString (MFC)

                Simple Transformations

                +

                		 Next

                Chapter 13. String Classes

                Table of Contents

                Simple Transformations
                Case Sensitivity
                Arbitrary Character Types
                Tokenizing
                Shrink to Fit
                CString (MFC)

                Simple Transformations

                Here are Standard, simple, and portable ways to perform common transformations on a string instance, such as "convert to all upper case." The word transformations diff --git a/libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html b/libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html index 454e01e881b..2cd970a12bf 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt05ch13s02.html @@ -1,13 +1,13 @@ -Case Sensitivity

                Case Sensitivity
                Prev Chapter 13. String Classes Next

                Case Sensitivity

                +Case Sensitivity

                Case Sensitivity
                Prev Chapter 13. String Classes Next

                Case Sensitivity

                The well-known-and-if-it-isn't-well-known-it-ought-to-be Guru of the Week discussions held on Usenet covered this topic in January of 1998. - Briefly, the challenge was, “write a 'ci_string' class which + Briefly, the challenge was, “write a 'ci_string' class which is identical to the standard 'string' class, but is case-insensitive in the same way as the (common but nonstandard) - C function stricmp()”. + C function stricmp()”. 

                    ci_string s( "AbCdE" );
 
diff --git a/libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html b/libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html
index 5d694747a6f..aa2afea53a6 100644
--- a/libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html
+++ b/libstdc++-v3/doc/html/manual/bk01pt05ch13s03.html
@@ -1,6 +1,6 @@
 
 
-Arbitrary Character Types
                Arbitrary Character Types
                Prev Chapter 13. String Classes Next
                Arbitrary Character Types
                
+Arbitrary Character Types
                Arbitrary Character Types
                Prev Chapter 13. String Classes Next
                Arbitrary Character Types
                
     
                The std::basic_string is tantalizingly general, in that
       it is parameterized on the type of the characters which it holds.
       In theory, you could whip up a Unicode character class and instantiate
diff --git a/libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html b/libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html
index 3334567e39d..12d1ee7fb5c 100644
--- a/libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html
+++ b/libstdc++-v3/doc/html/manual/bk01pt05ch13s04.html
@@ -1,6 +1,6 @@
 
 
-Tokenizing
                Tokenizing
                Prev Chapter 13. String Classes Next
                Tokenizing
                
+Tokenizing
                Tokenizing
                Prev Chapter 13. String Classes Next
                Tokenizing
                
     
                The Standard C (and C++) function strtok() leaves a lot to
       be desired in terms of user-friendliness.  It's unintuitive, it
       destroys the character string on which it operates, and it requires
diff --git a/libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html b/libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html
index fd2a77cb148..b6a5da10d20 100644
--- a/libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html
+++ b/libstdc++-v3/doc/html/manual/bk01pt05ch13s05.html
@@ -1,6 +1,6 @@
 
 
-Shrink to Fit
                Shrink to Fit
                Prev Chapter 13. String Classes Next
                Shrink to Fit
                
+Shrink to Fit
                Shrink to Fit
                Prev Chapter 13. String Classes Next
                Shrink to Fit
                
     
                From GCC 3.4 calling s.reserve(res) on a
       string s with res < s.capacity() will
       reduce the string's capacity to std::max(s.size(), res).
@@ -10,7 +10,7 @@
       std::string(str.data(), str.size()).swap(str);

                This is similar to the idiom for reducing a vector's memory usage - (see this FAQ + (see this FAQ entry) but the regular copy constructor cannot be used because libstdc++'s string is Copy-On-Write.

                Prev Up Next
                Tokenizing Home CString (MFC)
                diff --git a/libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html b/libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html index c6fb477f7c9..29ad197e1dd 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html +++ b/libstdc++-v3/doc/html/manual/bk01pt05ch13s06.html @@ -1,6 +1,6 @@ -CString (MFC)
                CString (MFC)
                Prev Chapter 13. String Classes Next

                CString (MFC)

                +CString (MFC)

                CString (MFC)
                Prev Chapter 13. String Classes Next

                CString (MFC)

                A common lament seen in various newsgroups deals with the Standard string class as opposed to the Microsoft Foundation Class called CString. Often programmers realize that a standard portable @@ -10,12 +10,12 @@

                Things are not as bad as they seem. In this message, Joe Buck points out a few very important things: -

                • The Standard string supports all the operations +

                  • The Standard string supports all the operations that CString does, with three exceptions. -

                  • Two of those exceptions (whitespace trimming and case +

                  • Two of those exceptions (whitespace trimming and case conversion) are trivial to implement. In fact, we do so on this page. -

                  • The third is CString::Format, which allows formatting +

                  • The third is CString::Format, which allows formatting in the style of sprintf. This deserves some mention:

                  The old libg++ library had a function called form(), which did much @@ -68,18 +68,18 @@ performance is O(n).

                  Joe Buck also pointed out some other things to keep in mind when comparing CString and the Standard string class: -

                  • CString permits access to its internal representation; coders +

                    • CString permits access to its internal representation; coders who exploited that may have problems moving to string. -

                    • Microsoft ships the source to CString (in the files +

                    • Microsoft ships the source to CString (in the files MFC\SRC\Str{core,ex}.cpp), so you could fix the allocation bug and rebuild your MFC libraries. Note: It looks like the CString shipped with VC++6.0 has fixed this, although it may in fact have been one of the VC++ SPs that did it. -

                    • string operations like this have O(n) complexity +

                    • string operations like this have O(n) complexity if the implementors do it correctly. The libstdc++ implementors did it correctly. Other vendors might not. -

                    • While parts of the SGI STL are used in libstdc++, their +

                    • While parts of the SGI STL are used in libstdc++, their string class is not. The SGI string is essentially vector<char> and does not do any reference counting like libstdc++'s does. (It is O(n), though.) diff --git a/libstdc++-v3/doc/html/manual/bk01pt08ch19.html b/libstdc++-v3/doc/html/manual/bk01pt08ch19.html index f5474946535..6b6bb02dbde 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt08ch19.html +++ b/libstdc++-v3/doc/html/manual/bk01pt08ch19.html @@ -1,11 +1,11 @@ -Chapter 19. Predefined

                      Chapter 19. Predefined
                      Prev Part VIII.  +Chapter 19. Predefined
                      Chapter 19. Predefined
                      Prev Part VIII.  Iterators - Next

                      Chapter 19. Predefined

                      Table of Contents

                      Iterators vs. Pointers
                      One Past the End

                      Iterators vs. Pointers

                      +

                      		 Next

                      Chapter 19. Predefined

                      Table of Contents

                      Iterators vs. Pointers
                      One Past the End

                      Iterators vs. Pointers

                      The following -FAQ entry points out that +FAQ entry points out that iterators are not implemented as pointers. They are a generalization of pointers, but they are implemented in libstdc++ as separate classes. diff --git a/libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html b/libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html index 8988b2316b8..2a0e28d40da 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt08ch19s02.html @@ -1,6 +1,6 @@ -One Past the End

                      One Past the End
                      Prev Chapter 19. Predefined Next

                      One Past the End

                      This starts off sounding complicated, but is actually very easy, +One Past the End

                      One Past the End
                      Prev Chapter 19. Predefined Next

                      One Past the End

                      This starts off sounding complicated, but is actually very easy, especially towards the end. Trust me.

                      Beginners usually have a little trouble understand the whole 'past-the-end' thing, until they remember their early algebra classes @@ -9,15 +9,15 @@

                      First, some history, and a reminder of some of the funkier rules in C and C++ for builtin arrays. The following rules have always been true for both languages: -

                      1. You can point anywhere in the array, or to the first element +

                        1. You can point anywhere in the array, or to the first element past the end of the array. A pointer that points to one past the end of the array is guaranteed to be as unique as a pointer to somewhere inside the array, so that you can compare such pointers safely. -

                        2. You can only dereference a pointer that points into an array. +

                        3. You can only dereference a pointer that points into an array. If your array pointer points outside the array -- even to just one past the end -- and you dereference it, Bad Things happen. -

                        4. Strictly speaking, simply pointing anywhere else invokes +

                        5. Strictly speaking, simply pointing anywhere else invokes undefined behavior. Most programs won't puke until such a pointer is actually dereferenced, but the standards leave that up to the platform. diff --git a/libstdc++-v3/doc/html/manual/bk01pt09ch20.html b/libstdc++-v3/doc/html/manual/bk01pt09ch20.html index a1055e56225..a343f9c50f4 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt09ch20.html +++ b/libstdc++-v3/doc/html/manual/bk01pt09ch20.html @@ -1,9 +1,9 @@ -Chapter 20. Mutating

                          Chapter 20. Mutating
                          Prev Part IX.  +Chapter 20. Mutating
                          Chapter 20. Mutating
                          Prev Part IX.  Algorithms - Next

                          Chapter 20. Mutating

                          Table of Contents

                          swap
                          Specializations

                          swap

                          Specializations

                          If you call std::swap(x,y); where x and y are standard +

                          		 Next

                          Chapter 20. Mutating

                          Table of Contents

                          swap
                          Specializations

                          swap

                          Specializations

                          If you call std::swap(x,y); where x and y are standard containers, then the call will automatically be replaced by a call to x.swap(y); instead.

                          This allows member functions of each container class to take over, and diff --git a/libstdc++-v3/doc/html/manual/bk01pt09pr02.html b/libstdc++-v3/doc/html/manual/bk01pt09pr02.html index 420cb81b855..d03d0f22558 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt09pr02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt09pr02.html @@ -1,17 +1,17 @@ -

                          Prev Part IX.  +
                          Prev Part IX.  Algorithms - Next

                          +

                          		 Next

                          The neatest accomplishment of the algorithms chapter is that all the work is done via iterators, not containers directly. This means two important things: -

                          1. +

                            1. Anything that behaves like an iterator can be used in one of these algorithms. Raw pointers make great candidates, thus built-in arrays are fine containers, as well as your own iterators. -

                            2. +

                            3. The algorithms do not (and cannot) affect the container as a whole; only the things between the two iterator endpoints. If you pass a range of iterators only enclosing the middle third of diff --git a/libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html b/libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html index e77fa847b49..31c37c741cf 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt10ch23s02.html @@ -1,6 +1,6 @@ -C99

                              C99
                              Prev Chapter 23. Interacting with C Next

                              C99

                              In addition to the other topics on this page, we'll note here some +C99

                              C99
                              Prev Chapter 23. Interacting with C Next

                              C99

                              In addition to the other topics on this page, we'll note here some of the C99 features that appear in libstdc++.

                              The C99 features depend on the --enable-c99 configure flag. This flag is already on by default, but it can be disabled by the diff --git a/libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html b/libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html index 7fce554de21..b713ad2ef02 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt11ch25s02.html @@ -1,6 +1,6 @@ -Buffering

                              Buffering
                              Prev Chapter 25. Stream Buffers Next

                              Buffering

                              First, are you sure that you understand buffering? Particularly +Buffering

                              Buffering
                              Prev Chapter 25. Stream Buffers Next

                              Buffering

                              First, are you sure that you understand buffering? Particularly the fact that C++ may not, in fact, have anything to do with it?

                              The rules for buffering can be a little odd, but they aren't any different from those of C. (Maybe that's why they can be a bit diff --git a/libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html b/libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html index 45151c1e649..4366e8fd8c0 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt11ch27s02.html @@ -1,6 +1,6 @@ -Binary Input and Output

                              Binary Input and Output
                              Prev Chapter 27. File Based Streams Next

                              Binary Input and Output

                              +Binary Input and Output

                              Binary Input and Output
                              Prev Chapter 27. File Based Streams Next

                              Binary Input and Output

                              The first and most important thing to remember about binary I/O is that opening a file with ios::binary is not, repeat not, the only thing you have to do. It is not a silver @@ -38,26 +38,26 @@ of formatting functions and classes to perform something which requires that formatting not be done? There are a seemingly infinite number of solutions, and a few are listed here: -

                              • “Derive your own fstream-type classes and write your own +

                                • “Derive your own fstream-type classes and write your own <</>> operators to do binary I/O on whatever data - types you're using.” + types you're using.”

                                  This is a Bad Thing, because while the compiler would probably be just fine with it, other humans are going to be confused. The overloaded bitshift operators have a well-defined meaning (formatting), and this breaks it. -

                                • - “Build the file structure in memory, then +

                                • + “Build the file structure in memory, then mmap() the file and copy the structure. - ” + ”

                                  Well, this is easy to make work, and easy to break, and is pretty equivalent to using ::read() and ::write() directly, and makes no use of the iostream library at all... -

                                • - “Use streambufs, that's what they're there for.” +

                                • + “Use streambufs, that's what they're there for.”

                                  While not trivial for the beginner, this is the best of all solutions. The streambuf/filebuf layer is the layer that is diff --git a/libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html b/libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html index 22fa0879445..69fa0f12ec1 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt11ch28s02.html @@ -1,6 +1,6 @@ -Performance

                                  Performance
                                  Prev Chapter 28. Interacting with C Next

                                  Performance

                                  +Performance

                                  Performance
                                  Prev Chapter 28. Interacting with C Next

                                  Performance

                                  Pathetic Performance? Ditch C.

                                  It sounds like a flame on C, but it isn't. Really. Calm down. I'm just saying it to get your attention. diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html b/libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html index 4a2ddb809e3..2605ad3b453 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch30s02.html @@ -1,6 +1,6 @@ -Semantics

                                  Semantics
                                  Prev Chapter 30. Debug Mode Next

                                  Semantics

                                  +Semantics

                                  Semantics
                                  Prev Chapter 30. Debug Mode Next

                                  Semantics

                                  A program that uses the C++ standard library correctly will maintain the same semantics under debug mode as it had with the normal (release) library. All functional and exception-handling @@ -36,7 +36,7 @@ (N.B. In GCC 3.4.x and 4.0.0, due to a bug, -D_GLIBXX_DEBUG_PEDANTIC was also needed. The problem has been fixed in GCC 4.0.1 and later versions.)

                                  The following library components provide extra debugging - capabilities in debug mode:

                                  • std::basic_string (no safe iterators and see note below)

                                  • std::bitset

                                  • std::deque

                                  • std::list

                                  • std::map

                                  • std::multimap

                                  • std::multiset

                                  • std::set

                                  • std::vector

                                  • std::unordered_map

                                  • std::unordered_multimap

                                  • std::unordered_set

                                  • std::unordered_multiset

                                  N.B. although there are precondition checks for some string operations, + capabilities in debug mode:

                                  • std::basic_string (no safe iterators and see note below)

                                  • std::bitset

                                  • std::deque

                                  • std::list

                                  • std::map

                                  • std::multimap

                                  • std::multiset

                                  • std::set

                                  • std::vector

                                  • std::unordered_map

                                  • std::unordered_multimap

                                  • std::unordered_set

                                  • std::unordered_multiset

                                  N.B. although there are precondition checks for some string operations, e.g. operator[], they will not always be run when using the char and wchar_t specialisations (std::string and diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html b/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html index 089058c2ff7..fe879cb7393 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch30s03.html @@ -1,7 +1,7 @@ -Using

                                  Using
                                  Prev Chapter 30. Debug Mode Next

                                  Using

                                  -

                                  Using the Debug Mode

                                  To use the libstdc++ debug mode, compile your application with the +Using

                                  Using
                                  Prev Chapter 30. Debug Mode Next

                                  Using

                                  +

                                  Using the Debug Mode

                                  To use the libstdc++ debug mode, compile your application with the compiler flag -D_GLIBCXX_DEBUG. Note that this flag changes the sizes and behavior of standard class templates such as std::vector, and therefore you can only link code @@ -10,7 +10,7 @@ units.

                                  By default, error messages are formatted to fit on lines of about 78 characters. The environment variable GLIBCXX_DEBUG_MESSAGE_LENGTH can be used to request a - different length.

                                  Using a Specific Debug Container

                                  When it is not feasible to recompile your entire application, or + different length.

                                  Using a Specific Debug Container

                                  When it is not feasible to recompile your entire application, or only specific containers need checking, debugging containers are available as GNU extensions. These debugging containers are functionally equivalent to the standard drop-in containers used in @@ -19,6 +19,6 @@ mode or with debug mode. The following table provides the names and headers of the debugging containers: -

                                  Table 30.1. Debugging Containers

                                  ContainerHeaderDebug containerDebug header
                                  std::bitsetbitset__gnu_debug::bitsetbitset
                                  std::dequedeque__gnu_debug::dequedeque
                                  std::listlist__gnu_debug::listlist
                                  std::mapmap__gnu_debug::mapmap
                                  std::multimapmap__gnu_debug::multimapmap
                                  std::multisetset__gnu_debug::multisetset
                                  std::setset__gnu_debug::setset
                                  std::stringstring__gnu_debug::stringstring
                                  std::wstringstring__gnu_debug::wstringstring
                                  std::basic_stringstring__gnu_debug::basic_stringstring
                                  std::vectorvector__gnu_debug::vectorvector

                                  In addition, when compiling in C++0x mode, these additional +

                                  Table 30.1. Debugging Containers

                                  ContainerHeaderDebug containerDebug header
                                  std::bitsetbitset__gnu_debug::bitsetbitset
                                  std::dequedeque__gnu_debug::dequedeque
                                  std::listlist__gnu_debug::listlist
                                  std::mapmap__gnu_debug::mapmap
                                  std::multimapmap__gnu_debug::multimapmap
                                  std::multisetset__gnu_debug::multisetset
                                  std::setset__gnu_debug::setset
                                  std::stringstring__gnu_debug::stringstring
                                  std::wstringstring__gnu_debug::wstringstring
                                  std::basic_stringstring__gnu_debug::basic_stringstring
                                  std::vectorvector__gnu_debug::vectorvector

                                  In addition, when compiling in C++0x mode, these additional containers have additional debug capability. -

                                  Table 30.2. Debugging Containers C++0x

                                  ContainerHeaderDebug containerDebug header
                                  std::unordered_mapunordered_map__gnu_debug::unordered_mapunordered_map
                                  std::unordered_multimapunordered_map__gnu_debug::unordered_multimapunordered_map
                                  std::unordered_setunordered_set__gnu_debug::unordered_setunordered_set
                                  std::unordered_multisetunordered_set__gnu_debug::unordered_multisetunordered_set

                                  Prev Up Next
                                  Semantics Home Design
                                  +

                                  Table 30.2. Debugging Containers C++0x

                                  ContainerHeaderDebug containerDebug header
                                  std::unordered_mapunordered_map__gnu_debug::unordered_mapunordered_map
                                  std::unordered_multimapunordered_map__gnu_debug::unordered_multimapunordered_map
                                  std::unordered_setunordered_set__gnu_debug::unordered_setunordered_set
                                  std::unordered_multisetunordered_set__gnu_debug::unordered_multisetunordered_set

                                  Prev Up Next
                                  Semantics Home Design
                                  diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html b/libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html index 32dc8d72c01..862789635a7 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch30s04.html @@ -1,11 +1,11 @@ -Design
                                  Design
                                  Prev Chapter 30. Debug Mode Next

                                  Design

                                  -

                                  Goals

                                  +Design

                                  Design
                                  Prev Chapter 30. Debug Mode Next

                                  Design

                                  +

                                  Goals

                                  The libstdc++ debug mode replaces unsafe (but efficient) standard containers and iterators with semantically equivalent safe standard containers and iterators to aid in debugging user programs. The - following goals directed the design of the libstdc++ debug mode:

                                  • Correctness: the libstdc++ debug mode must not change + following goals directed the design of the libstdc++ debug mode:

                                    • Correctness: the libstdc++ debug mode must not change the semantics of the standard library for all cases specified in the ANSI/ISO C++ standard. The essence of this constraint is that any valid C++ program should behave in the same manner regardless @@ -16,18 +16,18 @@ valid. A program that is not valid C++ (e.g., invokes undefined behavior) is not required to behave similarly, although the debug mode will abort with a diagnostic when it detects undefined - behavior.

                                    • Performance: the additional of the libstdc++ debug mode + behavior.

                                    • Performance: the additional of the libstdc++ debug mode must not affect the performance of the library when it is compiled in release mode. Performance of the libstdc++ debug mode is secondary (and, in fact, will be worse than the release - mode).

                                    • Usability: the libstdc++ debug mode should be easy to + mode).

                                    • Usability: the libstdc++ debug mode should be easy to use. It should be easily incorporated into the user's development environment (e.g., by requiring only a single new compiler switch) and should produce reasonable diagnostics when it detects a problem with the user program. Usability also involves detection of errors when using the debug mode incorrectly, e.g., by linking a release-compiled object against a debug-compiled object if in - fact the resulting program will not run correctly.

                                    • Minimize recompilation: While it is expected that + fact the resulting program will not run correctly.

                                    • Minimize recompilation: While it is expected that users recompile at least part of their program to use debug mode, the amount of recompilation affects the detect-compile-debug turnaround time. This indirectly affects the @@ -39,24 +39,24 @@ higher-numbered conformance levels are more usable (i.e., require less recompilation) but are more complicated to implement than the lower-numbered conformance levels. -

                                      1. Full recompilation: The user must recompile his or +

                                        1. Full recompilation: The user must recompile his or her entire application and all C++ libraries it depends on, including the C++ standard library that ships with the compiler. This must be done even if only a small part of the - program can use debugging features.

                                        2. Full user recompilation: The user must recompile + program can use debugging features.

                                        3. Full user recompilation: The user must recompile his or her entire application and all C++ libraries it depends on, but not the C++ standard library itself. This must be done even if only a small part of the program can use debugging features. This can be achieved given a full recompilation system by compiling two versions of the standard library when the compiler is installed and linking against the appropriate - one, e.g., a multilibs approach.

                                        4. Partial recompilation: The user must recompile the + one, e.g., a multilibs approach.

                                        5. Partial recompilation: The user must recompile the parts of his or her application and the C++ libraries it depends on that will use the debugging facilities directly. This means that any code that uses the debuggable standard containers would need to be recompiled, but code that does not use them (but may, for instance, use IOStreams) - would not have to be recompiled.

                                        6. Per-use recompilation: The user must recompile the + would not have to be recompiled.

                                        7. Per-use recompilation: The user must recompile the parts of his or her application and the C++ libraries it depends on where debugging should occur, and any other code that interacts with those containers. This means that a set of @@ -74,7 +74,7 @@ behavior is technically a violation of the One Definition Rule, this ability tends to be very important in practice. The libstdc++ debug mode supports this level of - recompilation.

                                        8. Per-unit recompilation: The user must only + recompilation.

                                        9. Per-unit recompilation: The user must only recompile the translation units where checking should occur, regardless of where debuggable standard containers are used. This has also been dubbed "-g mode", @@ -89,10 +89,10 @@ (performance regression) or allocating extra memory associated with each iterator with new (changes the program semantics).

                                        -

                                  Methods

                                  +

                              Methods

                              This section provides an overall view of the design of the libstdc++ debug mode and details the relationship between design - decisions and the stated design goals.

                              The Wrapper Model

                              The libstdc++ debug mode uses a wrapper model where the + decisions and the stated design goals.

                              The Wrapper Model

                              The libstdc++ debug mode uses a wrapper model where the debugging versions of library components (e.g., iterators and containers) form a layer on top of the release versions of the library components. The debugging components first verify that the @@ -109,19 +109,19 @@ their associated containers, which are necessary to detect certain types of standard library usage errors such as dereferencing past-the-end iterators or inserting into a container using an - iterator from a different container.

                              Safe Iterators

                              Iterator wrappers provide a debugging layer over any iterator that + iterator from a different container.

                              Safe Iterators

                              Iterator wrappers provide a debugging layer over any iterator that is attached to a particular container, and will manage the information detailing the iterator's state (singular, dereferenceable, etc.) and tracking the container to which the iterator is attached. Because iterators have a well-defined, common interface the iterator wrapper is implemented with the iterator adaptor class template __gnu_debug::_Safe_iterator, - which takes two template parameters:

                              • Iterator: The underlying iterator type, which must + which takes two template parameters:

                                • Iterator: The underlying iterator type, which must be either the iterator or const_iterator - typedef from the sequence type this iterator can reference.

                                • Sequence: The type of sequence that this iterator + typedef from the sequence type this iterator can reference.

                                • Sequence: The type of sequence that this iterator references. This sequence must be a safe sequence (discussed below) whose iterator or const_iterator typedef - is the type of the safe iterator.

                              Safe Sequences (Containers)

                              Container wrappers provide a debugging layer over a particular + is the type of the safe iterator.

                  Safe Sequences (Containers)

                  Container wrappers provide a debugging layer over a particular container type. Because containers vary greatly in the member functions they support and the semantics of those member functions (especially in the area of iterator invalidation), container @@ -157,7 +157,7 @@ template<typename _Tp, typename _Allocator = allocator<_Tp> // duplicate std::list interface with debugging semantics }; -

                Precondition Checking

                The debug mode operates primarily by checking the preconditions of +

                Precondition Checking

                The debug mode operates primarily by checking the preconditions of all standard library operations that it supports. Preconditions that are always checked (regardless of whether or not we are in debug mode) are checked via the __check_xxx macros defined @@ -184,7 +184,7 @@ template<typename _Tp, typename _Allocator = allocator<_Tp> cousin _GLIBCXX_DEBUG_PEDASSERT, or the assertion check macro that supports more advance formulation of error messages, _GLIBCXX_DEBUG_VERIFY. These macros are - documented more thoroughly in the debug mode source code.

                Release- and debug-mode coexistence

                The libstdc++ debug mode is the first debug mode we know of that + documented more thoroughly in the debug mode source code.

                Release- and debug-mode coexistence

                The libstdc++ debug mode is the first debug mode we know of that is able to provide the "Per-use recompilation" (4) guarantee, that allows release-compiled and debug-compiled code to be linked and executed together without causing unpredictable behavior. This @@ -200,7 +200,7 @@ template<typename _Tp, typename _Allocator = allocator<_Tp> recompilation but have had to give up some checking of the std::basic_string class template (namely, safe iterators). -

                Compile-time coexistence of release- and debug-mode components

                Both the release-mode components and the debug-mode +

                Compile-time coexistence of release- and debug-mode components

                Both the release-mode components and the debug-mode components need to exist within a single translation unit so that the debug versions can wrap the release versions. However, only one of these components should be user-visible at any particular @@ -254,7 +254,7 @@ namespace std // namespace __debug __attribute__ ((strong)); inline namespace __debug { } } -

                Link- and run-time coexistence of release- and +
                Link- and run-time coexistence of release- and debug-mode components

                Because each component has a distinct and separate release and debug implementation, there are are no issues with link-time coexistence: the separate namespaces result in different mangled @@ -301,11 +301,11 @@ test02() release-mode basic_string? While the answer could be "both", and the difference hidden via renaming a la the debug/release containers, we must note two things about locale - facets:

                1. They exist as shared state: one can create a facet in one + facets:

                  1. They exist as shared state: one can create a facet in one translation unit and access the facet via the same type name in a different translation unit. This means that we cannot have two different versions of locale facets, because the types would not be - the same across debug/release-mode translation unit barriers.

                  2. They have virtual functions returning strings: these functions + the same across debug/release-mode translation unit barriers.

                  3. They have virtual functions returning strings: these functions mangle in the same way regardless of the mangling of their return types (see above), and their precise signatures can be relied upon by users because they may be overridden in derived classes.

                  With the design of libstdc++ debug mode, we cannot effectively hide @@ -316,24 +316,24 @@ test02() changes. The effect on users is expected to be minimal, as there are simple alternatives (e.g., __gnu_debug::basic_string), and the usability benefit we gain from the ability to mix debug- and - release-compiled translation units is enormous.

                Alternatives for Coexistence

                The coexistence scheme above was chosen over many alternatives, + release-compiled translation units is enormous.

                Alternatives for Coexistence

                The coexistence scheme above was chosen over many alternatives, including language-only solutions and solutions that also required extensions to the C++ front end. The following is a partial list of - solutions, with justifications for our rejection of each.

                • Completely separate debug/release libraries: This is by + solutions, with justifications for our rejection of each.

                  • Completely separate debug/release libraries: This is by far the simplest implementation option, where we do not allow any coexistence of debug- and release-compiled translation units in a program. This solution has an extreme negative affect on usability, because it is quite likely that some libraries an application depends on cannot be recompiled easily. This would not meet our usability or minimize recompilation criteria - well.

                  • Add a Debug boolean template parameter: + well.

                  • Add a Debug boolean template parameter: Partial specialization could be used to select the debug implementation when Debug == true, and the state of _GLIBCXX_DEBUG could decide whether the default Debug argument is true or false. This option would break conformance with the C++ standard in both debug and release modes. This would - not meet our correctness criteria.

                  • Packaging a debug flag in the allocators: We could + not meet our correctness criteria.

                  • Packaging a debug flag in the allocators: We could reuse the Allocator template parameter of containers by adding a sentinel wrapper debug<> that signals the user's intention to use debugging, and pick up @@ -344,18 +344,18 @@ test02() (and more importantly), users that specify allocators instead of implicitly using the default allocator would not get debugging containers. Thus this solution fails the correctness - criteria.

                  • Define debug containers in another namespace, and employ + criteria.

                  • Define debug containers in another namespace, and employ a using declaration (or directive): This is an enticing option, because it would eliminate the need for the link_name extension by aliasing the templates. However, there is no true template aliasing mechanism is C++, because both using directives and using declarations disallow specialization. This method fails - the correctness criteria.

                  • Use implementation-specific properties of anonymous + the correctness criteria.

                  • Use implementation-specific properties of anonymous namespaces. See this post - This method fails the correctness criteria.

                  • Extension: allow reopening on namespaces: This would + This method fails the correctness criteria.

                  • Extension: allow reopening on namespaces: This would allow the debug mode to effectively alias the namespace std to an internal namespace, such as __gnu_std_debug, so that it is completely @@ -366,7 +366,7 @@ test02() instance, the program would have two std::cout objects! This solution would fails the minimize recompilation requirement, because we would only be able to - support option (1) or (2).

                  • Extension: use link name: This option involves + support option (1) or (2).

                  • Extension: use link name: This option involves complicated re-naming between debug-mode and release-mode components at compile time, and then a g++ extension called link name to recover the original names at link time. There @@ -388,23 +388,23 @@ test02() that breaks user specialization), and additional testcases will be added as we are able to identify other typical problem cases. These test cases will serve as a benchmark by which we can compare debug - mode implementations.

                Other Implementations

                + mode implementations.

                Other Implementations

                There are several existing implementations of debug modes for C++ standard library implementations, although none of them directly supports debugging for programs using libstdc++. The existing - implementations include:

                • SafeSTL: + implementations include:

                  • SafeSTL: SafeSTL was the original debugging version of the Standard Template Library (STL), implemented by Cay S. Horstmann on top of the Hewlett-Packard STL. Though it inspired much work in this area, it has not been kept up-to-date for use with modern compilers or C++ - standard library implementations.

                  • STLport: STLport is a free + standard library implementations.

                  • STLport: STLport is a free implementation of the C++ standard library derived from the SGI implementation, and ported to many other platforms. It includes a debug mode that uses a wrapper model (that in some ways inspired the libstdc++ debug mode design), although at the time of this writing the debug mode is somewhat incomplete and meets only the "Full user recompilation" (2) recompilation guarantee by requiring the user to link against a - different library in debug mode vs. release mode.

                  • Metrowerks CodeWarrior: The C++ standard library + different library in debug mode vs. release mode.

                  • Metrowerks CodeWarrior: The C++ standard library that ships with Metrowerks CodeWarrior includes a debug mode. It is a full debug-mode implementation (including debugging for CodeWarrior extensions) and is easy to use, although it meets only diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html b/libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html index 9418c79cdfe..64acc0aa5c3 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch31s02.html @@ -1,6 +1,6 @@ -Semantics

                    Semantics
                    Prev Chapter 31. Parallel Mode Next

                    Semantics

                    The parallel mode STL algorithms are currently not exception-safe, +Semantics

                    Semantics
                    Prev Chapter 31. Parallel Mode Next

                    Semantics

                    The parallel mode STL algorithms are currently not exception-safe, i.e. user-defined functors must not throw exceptions. Also, the order of execution is not guaranteed for some functions, of course. Therefore, user-defined functors should not have any concurrent side effects. diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html b/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html index 265a3116022..542d9bed0c9 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch31s03.html @@ -1,6 +1,6 @@ -Using

                    Using
                    Prev Chapter 31. Parallel Mode Next

                    Using

                    Prerequisite Compiler Flags

                    +Using

                    Using
                    Prev Chapter 31. Parallel Mode Next

                    Using

                    Prerequisite Compiler Flags

                    Any use of parallel functionality requires additional compiler and runtime support, in particular support for OpenMP. Adding this support is not difficult: just compile your application with the compiler @@ -17,7 +17,7 @@ In addition, hardware that supports atomic operations and a compiler as -march=i686, -march=native or -mcpu=v9. See the GCC manual for more information. -

                    Using Parallel Mode

                    +

                    Using Parallel Mode

                    To use the libstdc++ parallel mode, compile your application with the prerequisite flags as detailed above, and in addition add -D_GLIBCXX_PARALLEL. This will convert all @@ -34,7 +34,7 @@ In addition, hardware that supports atomic operations and a compiler if no instantiation of a container is passed between the two translation units. Parallel mode functionality has distinct linkage, and cannot be confused with normal mode symbols. -

                    Using Specific Parallel Components

                    When it is not feasible to recompile your entire application, or +

                    Using Specific Parallel Components

                    When it is not feasible to recompile your entire application, or only specific algorithms need to be parallel-aware, individual parallel algorithms can be made available explicitly. These parallel algorithms are functionally equivalent to the standard @@ -63,4 +63,4 @@ Then compile this code with the prerequisite compiler flags flags for atomic operations.)

                    The following table provides the names and headers of all the parallel algorithms that can be used in a similar manner: -

                    Table 31.1. Parallel Algorithms

                    AlgorithmHeaderParallel algorithmParallel header
                    std::accumulatenumeric__gnu_parallel::accumulateparallel/numeric
                    std::adjacent_differencenumeric__gnu_parallel::adjacent_differenceparallel/numeric
                    std::inner_productnumeric__gnu_parallel::inner_productparallel/numeric
                    std::partial_sumnumeric__gnu_parallel::partial_sumparallel/numeric
                    std::adjacent_findalgorithm__gnu_parallel::adjacent_findparallel/algorithm
                    std::countalgorithm__gnu_parallel::countparallel/algorithm
                    std::count_ifalgorithm__gnu_parallel::count_ifparallel/algorithm
                    std::equalalgorithm__gnu_parallel::equalparallel/algorithm
                    std::findalgorithm__gnu_parallel::findparallel/algorithm
                    std::find_ifalgorithm__gnu_parallel::find_ifparallel/algorithm
                    std::find_first_ofalgorithm__gnu_parallel::find_first_ofparallel/algorithm
                    std::for_eachalgorithm__gnu_parallel::for_eachparallel/algorithm
                    std::generatealgorithm__gnu_parallel::generateparallel/algorithm
                    std::generate_nalgorithm__gnu_parallel::generate_nparallel/algorithm
                    std::lexicographical_comparealgorithm__gnu_parallel::lexicographical_compareparallel/algorithm
                    std::mismatchalgorithm__gnu_parallel::mismatchparallel/algorithm
                    std::searchalgorithm__gnu_parallel::searchparallel/algorithm
                    std::search_nalgorithm__gnu_parallel::search_nparallel/algorithm
                    std::transformalgorithm__gnu_parallel::transformparallel/algorithm
                    std::replacealgorithm__gnu_parallel::replaceparallel/algorithm
                    std::replace_ifalgorithm__gnu_parallel::replace_ifparallel/algorithm
                    std::max_elementalgorithm__gnu_parallel::max_elementparallel/algorithm
                    std::mergealgorithm__gnu_parallel::mergeparallel/algorithm
                    std::min_elementalgorithm__gnu_parallel::min_elementparallel/algorithm
                    std::nth_elementalgorithm__gnu_parallel::nth_elementparallel/algorithm
                    std::partial_sortalgorithm__gnu_parallel::partial_sortparallel/algorithm
                    std::partitionalgorithm__gnu_parallel::partitionparallel/algorithm
                    std::random_shufflealgorithm__gnu_parallel::random_shuffleparallel/algorithm
                    std::set_unionalgorithm__gnu_parallel::set_unionparallel/algorithm
                    std::set_intersectionalgorithm__gnu_parallel::set_intersectionparallel/algorithm
                    std::set_symmetric_differencealgorithm__gnu_parallel::set_symmetric_differenceparallel/algorithm
                    std::set_differencealgorithm__gnu_parallel::set_differenceparallel/algorithm
                    std::sortalgorithm__gnu_parallel::sortparallel/algorithm
                    std::stable_sortalgorithm__gnu_parallel::stable_sortparallel/algorithm
                    std::unique_copyalgorithm__gnu_parallel::unique_copyparallel/algorithm

                    Prev Up Next
                    Semantics Home Design
                    +

                    Table 31.1. Parallel Algorithms

                    AlgorithmHeaderParallel algorithmParallel header
                    std::accumulatenumeric__gnu_parallel::accumulateparallel/numeric
                    std::adjacent_differencenumeric__gnu_parallel::adjacent_differenceparallel/numeric
                    std::inner_productnumeric__gnu_parallel::inner_productparallel/numeric
                    std::partial_sumnumeric__gnu_parallel::partial_sumparallel/numeric
                    std::adjacent_findalgorithm__gnu_parallel::adjacent_findparallel/algorithm
                    std::countalgorithm__gnu_parallel::countparallel/algorithm
                    std::count_ifalgorithm__gnu_parallel::count_ifparallel/algorithm
                    std::equalalgorithm__gnu_parallel::equalparallel/algorithm
                    std::findalgorithm__gnu_parallel::findparallel/algorithm
                    std::find_ifalgorithm__gnu_parallel::find_ifparallel/algorithm
                    std::find_first_ofalgorithm__gnu_parallel::find_first_ofparallel/algorithm
                    std::for_eachalgorithm__gnu_parallel::for_eachparallel/algorithm
                    std::generatealgorithm__gnu_parallel::generateparallel/algorithm
                    std::generate_nalgorithm__gnu_parallel::generate_nparallel/algorithm
                    std::lexicographical_comparealgorithm__gnu_parallel::lexicographical_compareparallel/algorithm
                    std::mismatchalgorithm__gnu_parallel::mismatchparallel/algorithm
                    std::searchalgorithm__gnu_parallel::searchparallel/algorithm
                    std::search_nalgorithm__gnu_parallel::search_nparallel/algorithm
                    std::transformalgorithm__gnu_parallel::transformparallel/algorithm
                    std::replacealgorithm__gnu_parallel::replaceparallel/algorithm
                    std::replace_ifalgorithm__gnu_parallel::replace_ifparallel/algorithm
                    std::max_elementalgorithm__gnu_parallel::max_elementparallel/algorithm
                    std::mergealgorithm__gnu_parallel::mergeparallel/algorithm
                    std::min_elementalgorithm__gnu_parallel::min_elementparallel/algorithm
                    std::nth_elementalgorithm__gnu_parallel::nth_elementparallel/algorithm
                    std::partial_sortalgorithm__gnu_parallel::partial_sortparallel/algorithm
                    std::partitionalgorithm__gnu_parallel::partitionparallel/algorithm
                    std::random_shufflealgorithm__gnu_parallel::random_shuffleparallel/algorithm
                    std::set_unionalgorithm__gnu_parallel::set_unionparallel/algorithm
                    std::set_intersectionalgorithm__gnu_parallel::set_intersectionparallel/algorithm
                    std::set_symmetric_differencealgorithm__gnu_parallel::set_symmetric_differenceparallel/algorithm
                    std::set_differencealgorithm__gnu_parallel::set_differenceparallel/algorithm
                    std::sortalgorithm__gnu_parallel::sortparallel/algorithm
                    std::stable_sortalgorithm__gnu_parallel::stable_sortparallel/algorithm
                    std::unique_copyalgorithm__gnu_parallel::unique_copyparallel/algorithm

                    Prev Up Next
                    Semantics Home Design
                    diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html b/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html index 26ea42d8398..16178cbfca2 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html @@ -1,7 +1,7 @@ -Design
                    Design
                    Prev Chapter 31. Parallel Mode Next

                    Design

                    -

                    Interface Basics

                    +Design

                    Design
                    Prev Chapter 31. Parallel Mode Next

                    Design

                    +

                    Interface Basics

                    All parallel algorithms are intended to have signatures that are equivalent to the ISO C++ algorithms replaced. For instance, the std::adjacent_find function is declared as: @@ -36,13 +36,13 @@ function, if no parallel functions are deemed worthy), based on either compile-time or run-time conditions.

                    The available signature options are specific for the different algorithms/algorithm classes.

                    The general view of overloads for the parallel algorithms look like this: -

                    • ISO C++ signature

                    • ISO C++ signature + sequential_tag argument

                    • ISO C++ signature + algorithm-specific tag type +

                      • ISO C++ signature

                      • ISO C++ signature + sequential_tag argument

                      • ISO C++ signature + algorithm-specific tag type (several signatures)

                      Please note that the implementation may use additional functions (designated with the _switch suffix) to dispatch from the ISO C++ signature to the correct parallel version. Also, some of the algorithms do not have support for run-time conditions, so the last overload is therefore missing. -

                    Configuration and Tuning

                    Setting up the OpenMP Environment

                    +

                    Configuration and Tuning

                    Setting up the OpenMP Environment

                    Several aspects of the overall runtime environment can be manipulated by standard OpenMP function calls.

                    @@ -72,7 +72,7 @@ Other parts of the runtime environment able to be manipulated include nested parallelism (omp_set_nested), schedule kind (omp_set_schedule), and others. See the OpenMP documentation for more information. -

                    Compile Time Switches

                    +

                    Compile Time Switches

                    To force an algorithm to execute sequentially, even though parallelism is switched on in general via the macro _GLIBCXX_PARALLEL, add __gnu_parallel::sequential_tag() to the end @@ -126,7 +126,7 @@ several additional choices, namely __gnu_parallel::balanced_quicksort_tag. Multiway mergesort comes with the two splitting strategies for multi-way merging. The quicksort options cannot be used for stable_sort. -

                    Run Time Settings and Defaults

                    +

                    Run Time Settings and Defaults

                    The default parallelization strategy, the choice of specific algorithm strategy, the minimum threshold limits for individual parallel algorithms, and aspects of the underlying hardware can be specified as @@ -194,7 +194,7 @@ int main() return 0; } -

                    Implementation Namespaces

                    One namespace contain versions of code that are always +

                    Implementation Namespaces

                    One namespace contain versions of code that are always explicitly sequential: __gnu_serial.

                    Two namespaces contain the parallel mode: diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html b/libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html index 18598fcb319..6a10f32eea9 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch31s05.html @@ -1,6 +1,6 @@ -Testing

                    Testing
                    Prev Chapter 31. Parallel Mode Next

                    Testing

                    +Testing

                    Testing
                    Prev Chapter 31. Parallel Mode Next

                    Testing

                    Both the normal conformance and regression tests and the supplemental performance tests work.

                    diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch32s02.html b/libstdc++-v3/doc/html/manual/bk01pt12ch32s02.html index 70f0eef3199..e3db40de94f 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch32s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch32s02.html @@ -1,10 +1,10 @@ -Design

                    Design
                    Prev Chapter 32. Profile Mode Next

                    Design

                    -

                    Table 32.1. Code Location

                    Code LocationUse
                    libstdc++-v3/include/std/*Preprocessor code to redirect to profile extension headers.
                    libstdc++-v3/include/profile/*Profile extension public headers (map, vector, ...).
                    libstdc++-v3/include/profile/impl/*Profile extension internals. Implementation files are +Design
                    Design
                    Prev Chapter 32. Profile Mode Next

                    Design

                    +

                    Table 32.1. Code Location

                    Code LocationUse
                    libstdc++-v3/include/std/*Preprocessor code to redirect to profile extension headers.
                    libstdc++-v3/include/profile/*Profile extension public headers (map, vector, ...).
                    libstdc++-v3/include/profile/impl/*Profile extension internals. Implementation files are only included from impl/profiler.h, which is the only file included from the public headers.

                    -

                    Wrapper Model

                    +

                    Wrapper Model

                    In order to get our instrumented library version included instead of the release one, we use the same wrapper model as the debug mode. @@ -25,7 +25,7 @@ Currently, mixing the profile mode with debug and parallel extensions is not allowed. Mixing them at compile time will result in preprocessor errors. Mixing them at link time is undefined. -

                    Instrumentation

                    +

                    Instrumentation

                    Instead of instrumenting every public entry and exit point, we chose to add instrumentation on demand, as needed by individual diagnostics. @@ -44,7 +44,7 @@

                    All the instrumentation on/off compile time switches live in include/profile/profiler.h. -

                    Run Time Behavior

                    +

                    Run Time Behavior

                    For practical reasons, the instrumentation library processes the trace partially rather than dumping it to disk in raw form. Each event is processed when @@ -63,25 +63,25 @@ For details, see paper presented at CGO 2009. -

                    Analysis and Diagnostics

                    +

                    Analysis and Diagnostics

                    Final analysis takes place offline, and it is based entirely on the generated trace and debugging info in the application binary. See section Diagnostics for a list of analysis types that we plan to support.

                    The input to the analysis is a table indexed by profile type and call stack. The data type for each entry depends on the profile type. -

                    Cost Model

                    +

                    Cost Model

                    While it is likely that cost models become complex as we get into more sophisticated analysis, we will try to follow a simple set of rules at the beginning. -

                    • Relative benefit estimation: +

                      • Relative benefit estimation: The idea is to estimate or measure the cost of all operations in the original scenario versus the scenario we advise to switch to. For instance, when advising to change a vector to a list, an occurrence of the insert method will generally count as a benefit. Its magnitude depends on (1) the number of elements that get shifted and (2) whether it triggers a reallocation. -

                      • Synthetic measurements: +

                      • Synthetic measurements: We will measure the relative difference between similar operations on different containers. We plan to write a battery of small tests that compare the times of the executions of similar methods on different @@ -89,16 +89,16 @@ If this training phase is very quick, we may decide to perform it at library initialization time. The results can be cached on disk and reused across runs. -

                      • Timers: +

                      • Timers: We plan to use timers for operations of larger granularity, such as sort. For instance, we can switch between different sort methods on the fly and report the one that performs best for each call context. -

                      • Show stoppers: +

                      • Show stoppers: We may decide that the presence of an operation nullifies the advice. For instance, when considering switching from set to unordered_set, if we detect use of operator ++, we will simply not issue the advice, since this could signal that the use - care require a sorted container.

                    Reports

                    + care require a sorted container.

                    Reports

                    There are two types of reports. First, if we recognize a pattern for which we have a substitute that is likely to give better performance, we print the advice and estimated performance gain. The advice is usually associated @@ -110,7 +110,7 @@ the top 10 multimap locations which have the worst data locality in actual traversals. Although this does not offer a solution, it helps the user focus on the key problems and ignore the uninteresting ones. -

                    Testing

                    +

                    Testing

                    First, we want to make sure we preserve the behavior of the release mode. You can just type "make check-profile", which builds and runs the whole test suite in profile mode. diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch32s03.html b/libstdc++-v3/doc/html/manual/bk01pt12ch32s03.html index 36aaf9392da..f943e20f0e7 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch32s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch32s03.html @@ -1,6 +1,6 @@ -Extensions for Custom Containers

                    Extensions for Custom Containers
                    Prev Chapter 32. Profile Mode Next

                    Extensions for Custom Containers

                    +Extensions for Custom Containers

                    Extensions for Custom Containers
                    Prev Chapter 32. Profile Mode Next

                    Extensions for Custom Containers

                    Many large projects use their own data structures instead of the ones in the standard library. If these data structures are similar in functionality to the standard library, they can be instrumented with the same hooks diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch32s04.html b/libstdc++-v3/doc/html/manual/bk01pt12ch32s04.html index 4246904d4fe..70a142871d2 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch32s04.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch32s04.html @@ -1,6 +1,6 @@ -Empirical Cost Model

                    Empirical Cost Model
                    Prev Chapter 32. Profile Mode Next

                    Empirical Cost Model

                    +Empirical Cost Model

                    Empirical Cost Model
                    Prev Chapter 32. Profile Mode Next

                    Empirical Cost Model

                    Currently, the cost model uses formulas with predefined relative weights for alternative containers or container implementations. For instance, iterating through a vector is X times faster than iterating through a list. diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch32s05.html b/libstdc++-v3/doc/html/manual/bk01pt12ch32s05.html index 42fae0c1ed6..d64fd47518f 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch32s05.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch32s05.html @@ -1,6 +1,6 @@ -Implementation Issues

                    Implementation Issues
                    Prev Chapter 32. Profile Mode Next

                    Implementation Issues

                    Stack Traces

                    +Implementation Issues

                    Implementation Issues
                    Prev Chapter 32. Profile Mode Next

                    Implementation Issues

                    Stack Traces

                    Accurate stack traces are needed during profiling since we group events by call context and dynamic instance. Without accurate traces, diagnostics may be hard to interpret. For instance, when giving advice to the user @@ -11,24 +11,24 @@ _GLIBCXX_PROFILE_STACK_DEPTH can be set to 0 if you are willing to give up call context information, or to a small positive value to reduce run time overhead. -

                    Symbolization of Instruction Addresses

                    +

                    Symbolization of Instruction Addresses

                    The profiling and analysis phases use only instruction addresses. An external utility such as addr2line is needed to postprocess the result. We do not plan to add symbolization support in the profile extension. This would require access to symbol tables, debug information tables, external programs or libraries and other system dependent information. -

                    Concurrency

                    +

                    Concurrency

                    Our current model is simplistic, but precise. We cannot afford to approximate because some of our diagnostics require precise matching of operations to container instance and call context. During profiling, we keep a single information table per diagnostic. There is a single lock per information table. -

                    Using the Standard Library in the Instrumentation Implementation

                    +

                    Using the Standard Library in the Instrumentation Implementation

                    As much as we would like to avoid uses of stdlibc++ within our instrumentation library, containers such as unordered_map are very appealing. We plan to use them as long as they are named properly to avoid ambiguity. -

                    Malloc Hooks

                    +

                    Malloc Hooks

                    User applications/libraries can provide malloc hooks. When the implementation of the malloc hooks uses stdlibc++, there can be an infinite cycle between the profile mode instrumentation and the @@ -42,7 +42,7 @@ uses non-recursive locks. XXX: A definitive solution to this problem would be for the profile extension to use a custom allocator internally, and perhaps not to use libstdc++. -

                    Construction and Destruction of Global Objects

                    +

                    Construction and Destruction of Global Objects

                    The profiling library state is initialized at the first call to a profiling method. This allows us to record the construction of all global objects. However, we cannot do the same at destruction time. The trace is written diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch32s06.html b/libstdc++-v3/doc/html/manual/bk01pt12ch32s06.html index 475b2d4fffc..ec752d398de 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch32s06.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch32s06.html @@ -1,6 +1,6 @@ -Developer Information

                    Developer Information
                    Prev Chapter 32. Profile Mode Next

                    Developer Information

                    Big Picture

                    The profile mode headers are included with +Developer Information

                    Developer Information
                    Prev Chapter 32. Profile Mode Next

                    Developer Information

                    Big Picture

                    The profile mode headers are included with -D_GLIBCXX_PROFILE through preprocessor directives in include/std/*.

                    Instrumented implementations are provided in @@ -14,7 +14,7 @@ must ensure (1) that the call is guarded against reentrance and (2) that the call can be turned off at compile time using a -D_GLIBCXX_PROFILE_... compiler option. -

                    How To Add A Diagnostic

                    Let's say the diagnostic name is "magic". +

                    How To Add A Diagnostic

                    Let's say the diagnostic name is "magic".

                    If you need to instrument a header not already under include/profile/*, first edit the corresponding header under include/std/ and add a preprocessor directive such @@ -36,15 +36,15 @@ Hook names must start with __profcxx_. Make sure they transform in no code with -D_NO_GLBICXX_PROFILE_MAGIC. - Make sure all calls to any method in namespace __cxxprof_impl + Make sure all calls to any method in namespace __gnu_profile is protected against reentrance using macro - _GLIBCXX_PROFILE_IMPL_REENTRANCE_GUARD. - All names of methods in namespace __cxxprof_impl called from + _GLIBCXX_PROFILE_REENTRANCE_GUARD. + All names of methods in namespace __gnu_profile called from profiler.h must start with __trace_magic_.

                    Add the implementation of the diagnostic. -

                    • +

                      • Create new file include/profile/impl/profiler_magic.h. -

                      • +

                      • Define class __magic_info: public __object_info_base. This is the representation of a line in the object table. The __merge method is used to aggregate information @@ -53,10 +53,10 @@ as a number of small operations, e.g., number of words copied. The __write method is used to produce the raw trace. The __advice method is used to produce the advice string. -

                      • +

                      • Define class __magic_stack_info: public __magic_info. This defines the content of a line in the stack table. -

                      • +

                      • Define class __trace_magic: public __trace_base<__magic_info, __magic_stack_info>. It defines the content of the trace associated with this diagnostic. diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch32s07.html b/libstdc++-v3/doc/html/manual/bk01pt12ch32s07.html index cbe09f0f19d..b1f835d39b8 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch32s07.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch32s07.html @@ -1,6 +1,6 @@ -Diagnostics

                        Diagnostics
                        Prev Chapter 32. Profile Mode Next

                        Diagnostics

                        +Diagnostics

                        Diagnostics
                        Prev Chapter 32. Profile Mode Next

                        Diagnostics

                        The table below presents all the diagnostics we intend to implement. Each diagnostic has a corresponding compile time switch -D_GLIBCXX_PROFILE_<diagnostic>. @@ -18,7 +18,7 @@ A high accuracy means that the diagnostic is unlikely to be wrong. These grades are not perfect. They are just meant to guide users with specific needs or time budgets. -

                        Table 32.2. Diagnostics

                        GroupFlagBenefitCostFreq.Implemented
                        +

                        Table 32.2. Diagnostics

                        GroupFlagBenefitCostFreq.Implemented
                        CONTAINERS HASHTABLE_TOO_SMALL101 10yes
                          HASHTABLE_TOO_LARGE51 10yes
                          @@ -35,44 +35,44 @@ LOCALITY SOFTWARE_PREFETCH88 5no
                          RBTREE_LOCALITY48 5no
                          - FALSE_SHARING810 10no

                        Diagnostic Template

                        • Switch: + FALSE_SHARING

                        		810 10no

                        Diagnostic Template

                        • Switch: _GLIBCXX_PROFILE_<diagnostic>. -

                        • Goal: What problem will it diagnose? -

                        • Fundamentals:. - What is the fundamental reason why this is a problem

                        • Sample runtime reduction: +

                        • Goal: What problem will it diagnose? +

                        • Fundamentals:. + What is the fundamental reason why this is a problem

                        • Sample runtime reduction: Percentage reduction in execution time. When reduction is more than a constant factor, describe the reduction rate formula. -

                        • Recommendation: - What would the advise look like?

                        • To instrument: - What stdlibc++ components need to be instrumented?

                        • Analysis: - How do we decide when to issue the advice?

                        • Cost model: - How do we measure benefits? Math goes here.

                        • Example: +

                        • Recommendation: + What would the advise look like?

                        • To instrument: + What stdlibc++ components need to be instrumented?

                        • Analysis: + How do we decide when to issue the advice?

                        • Cost model: + How do we measure benefits? Math goes here.

                        • Example: 

                           program code
 ...
 advice sample

                          -

                        Containers

                        +

                    Containers

                    Switch: _GLIBCXX_PROFILE_CONTAINERS. -

                    Hashtable Too Small

                    • Switch: +

                      Hashtable Too Small

                      • Switch: _GLIBCXX_PROFILE_HASHTABLE_TOO_SMALL. -

                      • Goal: Detect hashtables with many +

                      • Goal: Detect hashtables with many rehash operations, small construction size and large destruction size. -

                      • Fundamentals: Rehash is very expensive. +

                      • Fundamentals: Rehash is very expensive. Read content, follow chains within bucket, evaluate hash function, place at - new location in different order.

                      • Sample runtime reduction: 36%. + new location in different order.

                      • Sample runtime reduction: 36%. Code similar to example below. -

                      • Recommendation: +

                      • Recommendation: Set initial size to N at construction site S. -

                      • To instrument: +

                      • To instrument: unordered_set, unordered_map constructor, destructor, rehash. -

                      • Analysis: +

                      • Analysis: For each dynamic instance of unordered_[multi]set|map, record initial size and call context of the constructor. Record size increase, if any, after each relevant operation such as insert. - Record the estimated rehash cost.

                      • Cost model: - Number of individual rehash operations * cost per rehash.

                      • Example: + Record the estimated rehash cost.

                      • Cost model: + Number of individual rehash operations * cost per rehash.

                      • Example: 

                         1 unordered_set<int> us;
 2 for (int k = 0; k < 1000000; ++k) {
@@ -81,24 +81,24 @@ advice sample
 
 foo.cc:1: advice: Changing initial unordered_set size from 10 to 1000000 saves 1025530 rehash operations.

                        -

                      Hashtable Too Large

                      • Switch: +

                      Hashtable Too Large

                      • Switch: _GLIBCXX_PROFILE_HASHTABLE_TOO_LARGE. -

                      • Goal: Detect hashtables which are +

                      • Goal: Detect hashtables which are never filled up because fewer elements than reserved are ever inserted. -

                      • Fundamentals: Save memory, which +

                      • Fundamentals: Save memory, which is good in itself and may also improve memory reference performance through - fewer cache and TLB misses.

                      • Sample runtime reduction: unknown. -

                      • Recommendation: + fewer cache and TLB misses.

                      • Sample runtime reduction: unknown. +

                      • Recommendation: Set initial size to N at construction site S. -

                      • To instrument: +

                      • To instrument: unordered_set, unordered_map constructor, destructor, rehash. -

                      • Analysis: +

                      • Analysis: For each dynamic instance of unordered_[multi]set|map, record initial size and call context of the constructor, and correlate it with its size at destruction time. -

                      • Cost model: - Number of iteration operations + memory saved.

                      • Example: +

                      • Cost model: + Number of iteration operations + memory saved.

                      • Example: 

                         1 vector<unordered_set<int>> v(100000, unordered_set<int>(100)) ;
 2 for (int k = 0; k < 100000; ++k) {
@@ -110,25 +110,25 @@ foo.cc:1: advice: Changing initial unordered_set size from 10 to 1000000 saves 1
 foo.cc:1: advice: Changing initial unordered_set size from 100 to 10 saves N
 bytes of memory and M iteration steps.

                        -

                      Inefficient Hash

                      • Switch: +

                      Inefficient Hash

                      • Switch: _GLIBCXX_PROFILE_INEFFICIENT_HASH. -

                      • Goal: Detect hashtables with polarized +

                      • Goal: Detect hashtables with polarized distribution. -

                      • Fundamentals: A non-uniform +

                      • Fundamentals: A non-uniform distribution may lead to long chains, thus possibly increasing complexity by a factor up to the number of elements. -

                      • Sample runtime reduction: factor up +

                      • Sample runtime reduction: factor up to container size. -

                      • Recommendation: Change hash function +

                      • Recommendation: Change hash function for container built at site S. Distribution score = N. Access score = S. Longest chain = C, in bucket B. -

                      • To instrument: +

                      • To instrument: unordered_set, unordered_map constructor, destructor, [], insert, iterator. -

                      • Analysis: +

                      • Analysis: Count the exact number of link traversals. -

                      • Cost model: - Total number of links traversed.

                      • Example: +

                      • Cost model: + Total number of links traversed.

                      • Example: 

                         class dumb_hash {
  public:
@@ -141,22 +141,22 @@ class dumb_hash {
     hs.find(i);
   }

                        -

                      Vector Too Small

                      • Switch: +

                      Vector Too Small

                      • Switch: _GLIBCXX_PROFILE_VECTOR_TOO_SMALL. -

                      • Goal:Detect vectors with many +

                      • Goal:Detect vectors with many resize operations, small construction size and large destruction size.. -

                      • Fundamentals:Resizing can be expensive. +

                      • Fundamentals:Resizing can be expensive. Copying large amounts of data takes time. Resizing many small vectors may - have allocation overhead and affect locality.

                      • Sample runtime reduction:%. -

                      • Recommendation: - Set initial size to N at construction site S.

                      • To instrument:vector. -

                      • Analysis: + have allocation overhead and affect locality.

                      • Sample runtime reduction:%. +

                      • Recommendation: + Set initial size to N at construction site S.

                      • To instrument:vector. +

                      • Analysis: For each dynamic instance of vector, record initial size and call context of the constructor. Record size increase, if any, after each relevant operation such as push_back. Record the estimated resize cost. -

                      • Cost model: - Total number of words copied * time to copy a word.

                      • Example: +

                      • Cost model: + Total number of words copied * time to copy a word.

                      • Example: 

                         1 vector<int> v;
 2 for (int k = 0; k < 1000000; ++k) {
@@ -166,21 +166,21 @@ class dumb_hash {
 foo.cc:1: advice: Changing initial vector size from 10 to 1000000 saves 
 copying 4000000 bytes and 20 memory allocations and deallocations.

                        -

                      Vector Too Large

                      • Switch: +

                      Vector Too Large

                      • Switch: _GLIBCXX_PROFILE_VECTOR_TOO_LARGE -

                      • Goal:Detect vectors which are +

                      • Goal:Detect vectors which are never filled up because fewer elements than reserved are ever inserted. -

                      • Fundamentals:Save memory, which +

                      • Fundamentals:Save memory, which is good in itself and may also improve memory reference performance through - fewer cache and TLB misses.

                      • Sample runtime reduction:%. -

                      • Recommendation: - Set initial size to N at construction site S.

                      • To instrument:vector. -

                      • Analysis: + fewer cache and TLB misses.

                      • Sample runtime reduction:%. +

                      • Recommendation: + Set initial size to N at construction site S.

                      • To instrument:vector. +

                      • Analysis: For each dynamic instance of vector, record initial size and call context of the constructor, and correlate it - with its size at destruction time.

                      • Cost model: - Total amount of memory saved.

                      • Example: + with its size at destruction time.

                      • Cost model: + Total amount of memory saved.

                      • Example: 

                         1 vector<vector<int>> v(100000, vector<int>(100)) ;
 2 for (int k = 0; k < 100000; ++k) {
@@ -192,27 +192,27 @@ copying 4000000 bytes and 20 memory allocations and deallocations.
 foo.cc:1: advice: Changing initial vector size from 100 to 10 saves N
 bytes of memory and may reduce the number of cache and TLB misses.

                        -

                      Vector to Hashtable

                      • Switch: +

                      Vector to Hashtable

                      • Switch: _GLIBCXX_PROFILE_VECTOR_TO_HASHTABLE. -

                      • Goal: Detect uses of +

                      • Goal: Detect uses of vector that can be substituted with unordered_set to reduce execution time. -

                      • Fundamentals: +

                      • Fundamentals: Linear search in a vector is very expensive, whereas searching in a hashtable - is very quick.

                      • Sample runtime reduction:factor up + is very quick.

                      • Sample runtime reduction:factor up to container size. -

                      • Recommendation:Replace +

                      • Recommendation:Replace vector with unordered_set at site S. -

                      • To instrument:vector - operations and access methods.

                      • Analysis: +

                      • To instrument:vector + operations and access methods.

                      • Analysis: For each dynamic instance of vector, record call context of the constructor. Issue the advice only if the only methods called on this vector are push_back, insert and find. -

                      • Cost model: +

                      • Cost model: Cost(vector::push_back) + cost(vector::insert) + cost(find, vector) - cost(unordered_set::insert) + cost(unordered_set::find). -

                      • Example: +

                      • Example: 

                         1  vector<int> v;
 ...
@@ -223,24 +223,24 @@ bytes of memory and may reduce the number of cache and TLB misses.
 foo.cc:1: advice: Changing "vector" to "unordered_set" will save about 500,000
 comparisons.

                        -

                      Hashtable to Vector

                      • Switch: +

                      Hashtable to Vector

                      • Switch: _GLIBCXX_PROFILE_HASHTABLE_TO_VECTOR. -

                      • Goal: Detect uses of +

                      • Goal: Detect uses of unordered_set that can be substituted with vector to reduce execution time. -

                      • Fundamentals: - Hashtable iterator is slower than vector iterator.

                      • Sample runtime reduction:95%. -

                      • Recommendation:Replace +

                      • Fundamentals: + Hashtable iterator is slower than vector iterator.

                      • Sample runtime reduction:95%. +

                      • Recommendation:Replace unordered_set with vector at site S. -

                      • To instrument:unordered_set - operations and access methods.

                      • Analysis: +

                      • To instrument:unordered_set + operations and access methods.

                      • Analysis: For each dynamic instance of unordered_set, record call context of the constructor. Issue the advice only if the number of find, insert and [] operations on this unordered_set are small relative to the number of elements, and methods begin or end - are invoked (suggesting iteration).

                      • Cost model: - Number of .

                      • Example: + are invoked (suggesting iteration).

                      • Cost model: + Number of .

                      • Example: 

                         1  unordered_set<int> us;
 ...
@@ -252,27 +252,27 @@ comparisons.
 foo.cc:1: advice: Changing "unordered_set" to "vector" will save about N
 indirections and may achieve better data locality.

                        -

                      Vector to List

                      • Switch: +

                      Vector to List

                      • Switch: _GLIBCXX_PROFILE_VECTOR_TO_LIST. -

                      • Goal: Detect cases where +

                      • Goal: Detect cases where vector could be substituted with list for better performance. -

                      • Fundamentals: +

                      • Fundamentals: Inserting in the middle of a vector is expensive compared to inserting in a list. -

                      • Sample runtime reduction:factor up to +

                      • Sample runtime reduction:factor up to container size. -

                      • Recommendation:Replace vector with list - at site S.

                      • To instrument:vector - operations and access methods.

                      • Analysis: +

                      • Recommendation:Replace vector with list + at site S.

                      • To instrument:vector + operations and access methods.

                      • Analysis: For each dynamic instance of vector, record the call context of the constructor. Record the overhead of each insert operation based on current size and insert position. Report instance with high insertion overhead. -

                      • Cost model: +

                      • Cost model: (Sum(cost(vector::method)) - Sum(cost(list::method)), for method in [push_back, insert, erase]) - + (Cost(iterate vector) - Cost(iterate list))

                      • Example: + + (Cost(iterate vector) - Cost(iterate list))

                      • Example: 

                         1  vector<int> v;
 2  for (int i = 0; i < 10000; ++i) {
@@ -282,22 +282,22 @@ indirections and may achieve better data locality.
 foo.cc:1: advice: Changing "vector" to "list" will save about 5,000,000 
 operations.

                        -

                      List to Vector

                      • Switch: +

                      List to Vector

                      • Switch: _GLIBCXX_PROFILE_LIST_TO_VECTOR. -

                      • Goal: Detect cases where +

                      • Goal: Detect cases where list could be substituted with vector for better performance. -

                      • Fundamentals: +

                      • Fundamentals: Iterating through a vector is faster than through a list. -

                      • Sample runtime reduction:64%. -

                      • Recommendation:Replace list with vector - at site S.

                      • To instrument:vector - operations and access methods.

                      • Analysis: +

                      • Sample runtime reduction:64%. +

                      • Recommendation:Replace list with vector + at site S.

                      • To instrument:vector + operations and access methods.

                      • Analysis: Issue the advice if there are no insert operations. -

                      • Cost model: +

                      • Cost model: (Sum(cost(vector::method)) - Sum(cost(list::method)), for method in [push_back, insert, erase]) - + (Cost(iterate vector) - Cost(iterate list))

                      • Example: + + (Cost(iterate vector) - Cost(iterate list))

                      • Example: 

                         1  list<int> l;
 ...
@@ -309,23 +309,23 @@ operations.
 foo.cc:1: advice: Changing "list" to "vector" will save about 1000000 indirect
 memory references.

                        -

                      Ordered to Unordered Associative Container

                      • Switch: +

                      Ordered to Unordered Associative Container

                      • Switch: _GLIBCXX_PROFILE_ORDERED_TO_UNORDERED. -

                      • Goal: Detect cases where ordered +

                      • Goal: Detect cases where ordered associative containers can be replaced with unordered ones. -

                      • Fundamentals: +

                      • Fundamentals: Insert and search are quicker in a hashtable than in - a red-black tree.

                      • Sample runtime reduction:52%. -

                      • Recommendation: - Replace set with unordered_set at site S.

                      • To instrument: + a red-black tree.

                      • Sample runtime reduction:52%. +

                      • Recommendation: + Replace set with unordered_set at site S.

                      • To instrument: set, multiset, map, - multimap methods.

                      • Analysis: + multimap methods.

                      • Analysis: Issue the advice only if we are not using operator ++ on any iterator on a particular [multi]set|map. -

                      • Cost model: +

                      • Cost model: (Sum(cost(hashtable::method)) - Sum(cost(rbtree::method)), for method in [insert, erase, find]) - + (Cost(iterate hashtable) - Cost(iterate rbtree))

                      • Example: + + (Cost(iterate hashtable) - Cost(iterate rbtree))

                      • Example: 

                         1  set<int> s;
 2  for (int i = 0; i < 100000; ++i) {
@@ -336,43 +336,43 @@ memory references.
 7    sum += *s.find(i);
 8  }

                        -

                    Algorithms

                    Switch: +

                    Algorithms

                    Switch: _GLIBCXX_PROFILE_ALGORITHMS. -

                    Sort Algorithm Performance

                    • Switch: +

                      Sort Algorithm Performance

                      • Switch: _GLIBCXX_PROFILE_SORT. -

                      • Goal: Give measure of sort algorithm +

                      • Goal: Give measure of sort algorithm performance based on actual input. For instance, advise Radix Sort over Quick Sort for a particular call context. -

                      • Fundamentals: +

                      • Fundamentals: See papers: A framework for adaptive algorithm selection in STAPL and Optimizing Sorting with Machine Learning Algorithms. -

                      • Sample runtime reduction:60%. -

                      • Recommendation: Change sort algorithm - at site S from X Sort to Y Sort.

                      • To instrument: sort - algorithm.

                      • Analysis: +

                      • Sample runtime reduction:60%. +

                      • Recommendation: Change sort algorithm + at site S from X Sort to Y Sort.

                      • To instrument: sort + algorithm.

                      • Analysis: Issue the advice if the cost model tells us that another sort algorithm would do better on this input. Requires us to know what algorithm we - are using in our sort implementation in release mode.

                      • Cost model: - Runtime(algo) for algo in [radix, quick, merge, ...]

                      • Example: + are using in our sort implementation in release mode.

                      • Cost model: + Runtime(algo) for algo in [radix, quick, merge, ...]

                      • Example:

                        -

                    Data Locality

                    Switch: +

                    Data Locality

                    Switch: _GLIBCXX_PROFILE_LOCALITY. -

                    Need Software Prefetch

                    • Switch: +

                      Need Software Prefetch

                      • Switch: _GLIBCXX_PROFILE_SOFTWARE_PREFETCH. -

                      • Goal: Discover sequences of indirect +

                      • Goal: Discover sequences of indirect memory accesses that are not regular, thus cannot be predicted by hardware prefetchers. -

                      • Fundamentals: +

                      • Fundamentals: Indirect references are hard to predict and are very expensive when they - miss in caches.

                      • Sample runtime reduction:25%. -

                      • Recommendation: Insert prefetch - instruction.

                      • To instrument: Vector iterator and + miss in caches.

                      • Sample runtime reduction:25%. +

                      • Recommendation: Insert prefetch + instruction.

                      • To instrument: Vector iterator and access operator []. -

                      • Analysis: +

                      • Analysis: First, get cache line size and page size from system. Then record iterator dereference sequences for which the value is a pointer. For each sequence within a container, issue a warning if successive pointer @@ -389,9 +389,9 @@ memory references. created by understanding the capability of the hardware prefetcher. This model could be trained automatically by running a set of synthetic cases. -

                      • Cost model: +

                      • Cost model: Total distance between pointer values of successive elements in vectors - of pointers.

                      • Example: + of pointers.

                      • Example: 

                         1 int zero = 0;
 2 vector<int*> v(10000000, &zero);
@@ -404,28 +404,28 @@ memory references.
 
 foo.cc:7: advice: Insert prefetch instruction.

                        -

                      Linked Structure Locality

                      • Switch: +

                      Linked Structure Locality

                      • Switch: _GLIBCXX_PROFILE_RBTREE_LOCALITY. -

                      • Goal: Give measure of locality of +

                      • Goal: Give measure of locality of objects stored in linked structures (lists, red-black trees and hashtables) with respect to their actual traversal patterns. -

                      • Fundamentals:Allocation can be tuned +

                      • Fundamentals:Allocation can be tuned to a specific traversal pattern, to result in better data locality. See paper: Custom Memory Allocation for Free. -

                      • Sample runtime reduction:30%. -

                      • Recommendation: +

                      • Sample runtime reduction:30%. +

                      • Recommendation: High scatter score N for container built at site S. Consider changing allocation sequence or choosing a structure conscious - allocator.

                      • To instrument: Methods of all - containers using linked structures.

                      • Analysis: + allocator.

                      • To instrument: Methods of all + containers using linked structures.

                      • Analysis: First, get cache line size and page size from system. Then record the number of successive elements that are on different line or page, for each traversal method such as find. Give advice only if the ratio between this number and the number of total node hops - is above a threshold.

                      • Cost model: - Sum(same_cache_line(this,previous))

                      • Example: + is above a threshold.

                      • Cost model: + Sum(same_cache_line(this,previous))

                      • Example: 

                          1  set<int> s;
  2  for (int i = 0; i < 10000000; ++i) {
@@ -449,58 +449,58 @@ foo.cc:7: advice: Insert prefetch instruction.
 foo.cc:5: advice: High scatter score NNN for set built here.  Consider changing
 the allocation sequence or switching to a structure conscious allocator.

                        -

                    Multithreaded Data Access

                    +

                    Multithreaded Data Access

                    The diagnostics in this group are not meant to be implemented short term. They require compiler support to know when container elements are written to. Instrumentation can only tell us when elements are referenced.

                    Switch: _GLIBCXX_PROFILE_MULTITHREADED. -

                    Data Dependence Violations at Container Level

                    • Switch: +

                      Data Dependence Violations at Container Level

                      • Switch: _GLIBCXX_PROFILE_DDTEST. -

                      • Goal: Detect container elements +

                      • Goal: Detect container elements that are referenced from multiple threads in the parallel region or across parallel regions. -

                      • Fundamentals: +

                      • Fundamentals: Sharing data between threads requires communication and perhaps locking, which may be expensive. -

                      • Sample runtime reduction:?%. -

                      • Recommendation: Change data - distribution or parallel algorithm.

                      • To instrument: Container access methods +

                      • Sample runtime reduction:?%. +

                      • Recommendation: Change data + distribution or parallel algorithm.

                      • To instrument: Container access methods and iterators. -

                      • Analysis: +

                      • Analysis: Keep a shadow for each container. Record iterator dereferences and container member accesses. Issue advice for elements referenced by multiple threads. See paper: The LRPD test: speculative run-time parallelization of loops with privatization and reduction parallelization. -

                      • Cost model: +

                      • Cost model: Number of accesses to elements referenced from multiple threads -

                      • Example: +

                      • Example:

                        -

                      False Sharing

                      • Switch: +

                      False Sharing

                      • Switch: _GLIBCXX_PROFILE_FALSE_SHARING. -

                      • Goal: Detect elements in the +

                      • Goal: Detect elements in the same container which share a cache line, are written by at least one thread, and accessed by different threads. -

                      • Fundamentals: Under these assumptions, +

                      • Fundamentals: Under these assumptions, cache protocols require communication to invalidate lines, which may be expensive. -

                      • Sample runtime reduction:68%. -

                      • Recommendation: Reorganize container - or use padding to avoid false sharing.

                      • To instrument: Container access methods +

                      • Sample runtime reduction:68%. +

                      • Recommendation: Reorganize container + or use padding to avoid false sharing.

                      • To instrument: Container access methods and iterators. -

                      • Analysis: +

                      • Analysis: First, get the cache line size. For each shared container, record all the associated iterator dereferences and member access methods with the thread id. Compare the address lists across threads to detect references in two different threads to the same cache line. Issue a warning only if the ratio to total references is significant. Do the same for iterator dereference values if they are - pointers.

                      • Cost model: + pointers.

                      • Cost model: Number of accesses to same cache line from different threads. -

                      • Example: +

                      • Example: 

                         1     vector<int> v(2, 0);
 2 #pragma omp parallel for shared(v, SIZE) schedule(static, 1)
@@ -512,7 +512,7 @@ OMP_NUM_THREADS=2 ./a.out
 foo.cc:1: advice: Change container structure or padding to avoid false 
 sharing in multithreaded access at foo.cc:4.  Detected N shared cache lines.

                        -

                    Statistics

                    +

                    Statistics

                    Switch: _GLIBCXX_PROFILE_STATISTICS.

                    diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch34s02.html b/libstdc++-v3/doc/html/manual/bk01pt12ch34s02.html index e1588498eb9..70e4d924cec 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch34s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch34s02.html @@ -1,6 +1,6 @@ -HP/SGI

                    HP/SGI
                    Prev Chapter 34. Containers Next

                    HP/SGI

                    +HP/SGI

                    HP/SGI
                    Prev Chapter 34. Containers Next

                    HP/SGI

                    A few extensions and nods to backwards-compatibility have been made with containers. Those dealing with older SGI-style allocators are dealt with elsewhere. The remaining ones all deal with bits: diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch34s03.html b/libstdc++-v3/doc/html/manual/bk01pt12ch34s03.html index 3e3b28d9998..b9f0849bf5a 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch34s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch34s03.html @@ -1,6 +1,6 @@ -Deprecated HP/SGI

                    Deprecated HP/SGI
                    Prev Chapter 34. Containers Next

                    Deprecated HP/SGI

                    +Deprecated HP/SGI

                    Deprecated HP/SGI
                    Prev Chapter 34. Containers Next

                    Deprecated HP/SGI

                    The SGI hashing classes hash_set and hash_set have been deprecated by the unordered_set, unordered_multiset, unordered_map, @@ -37,7 +37,7 @@ functions, as well as some extra constructors specifying the number of buckets, etc.

                    Why would you want to use a hashing class instead of the - “normal”implementations? Matt Austern writes: + “normal”implementations? Matt Austern writes:

                    [W]ith a well chosen hash function, hash tables generally provide much better average-case performance than diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch41s02.html b/libstdc++-v3/doc/html/manual/bk01pt12ch41s02.html index cd976c38f26..7d839e152ee 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch41s02.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch41s02.html @@ -1,6 +1,6 @@ -Implementation

                    Implementation
                    Prev Chapter 41. Concurrency Next

                    Implementation

                    Using Builtin Atomic Functions

                    The functions for atomic operations described above are either +Implementation

                    Implementation
                    Prev Chapter 41. Concurrency Next

                    Implementation

                    Using Builtin Atomic Functions

                    The functions for atomic operations described above are either implemented via compiler intrinsics (if the underlying host is capable) or by library fallbacks.

                    Compiler intrinsics (builtins) are always preferred. However, as the compiler builtins for atomics are not universally implemented, @@ -18,14 +18,14 @@ If builtins are possible for bool-sized integral types, If builtins are possible for int-sized integral types, _GLIBCXX_ATOMIC_BUILTINS_4 will be defined.

                    For the following hosts, intrinsics are enabled by default. -

                    • alpha

                    • ia64

                    • powerpc

                    • s390

                    For others, some form of -march may work. On +

                    • alpha

                    • ia64

                    • powerpc

                    • s390

                    For others, some form of -march may work. On non-ancient x86 hardware, -march=native usually does the trick.

                    For hosts without compiler intrinsics, but with capable hardware, hand-crafted assembly is selected. This is the case for the following hosts: -

                    • cris

                    • hppa

                    • i386

                    • i486

                    • m48k

                    • mips

                    • sparc

                    And for the rest, a simulated atomic lock via pthreads. +

                    • cris

                    • hppa

                    • i386

                    • i486

                    • m48k

                    • mips

                    • sparc

                    And for the rest, a simulated atomic lock via pthreads.

                    Detailed information about compiler intrinsics for atomic operations can be found in the GCC documentation.

                    More details on the library fallbacks from the porting section. -

                    Thread Abstraction

                    A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract +

                    Thread Abstraction

                    A thin layer above IEEE 1003.1 (i.e. pthreads) is used to abstract the thread interface for GCC. This layer is called "gthread," and is comprised of one header file that wraps the host's default thread layer with a POSIX-like interface. diff --git a/libstdc++-v3/doc/html/manual/bk01pt12ch41s03.html b/libstdc++-v3/doc/html/manual/bk01pt12ch41s03.html index cba67ced6b4..deb28ca2ca4 100644 --- a/libstdc++-v3/doc/html/manual/bk01pt12ch41s03.html +++ b/libstdc++-v3/doc/html/manual/bk01pt12ch41s03.html @@ -1,6 +1,6 @@ -Use

                    Use
                    Prev Chapter 41. Concurrency Next

                    Use

                    Typical usage of the last two constructs is demonstrated as follows: +Use

                    Use
                    Prev Chapter 41. Concurrency Next

                    Use

                    Typical usage of the last two constructs is demonstrated as follows: 

                     #include <ext/concurrence.h>
 
diff --git a/libstdc++-v3/doc/html/manual/bk01pt12pr03.html b/libstdc++-v3/doc/html/manual/bk01pt12pr03.html
index 68f3a89765d..a68ddced46d 100644
--- a/libstdc++-v3/doc/html/manual/bk01pt12pr03.html
+++ b/libstdc++-v3/doc/html/manual/bk01pt12pr03.html
@@ -1,15 +1,15 @@
 
 
-
                    Prev Part XII. 
+
                    Prev Part XII. 
   Extensions
   
- Next
                    
+
                    		 Next
                    
   Here we will make an attempt at describing the non-Standard extensions to
   the library.  Some of these are from SGI's STL, some of these are GNU's,
   and some just seemed to appear on the doorstep.
 
                    Before you leap in and use any of these
 extensions, be aware of two things:
-
                    1. 
+
                      1. 
      Non-Standard means exactly that.  
      
                        
        The behavior, and the very
@@ -18,7 +18,7 @@ extensions, be aware of two things:
        revision of C++.)  Also, other platforms, other compilers, other
        versions of g++ or libstdc++ may not recognize these names, or
        treat them differently, or... 
-     
                      2. 
+     
                      3. 
        You should know how to access these headers properly. 
      
                    Prev Up Next
                    Part XII. 
   Extensions
diff --git a/libstdc++-v3/doc/html/manual/bugs.html b/libstdc++-v3/doc/html/manual/bugs.html
index 12ed9a966fa..20da4a8fbf4 100644
--- a/libstdc++-v3/doc/html/manual/bugs.html
+++ b/libstdc++-v3/doc/html/manual/bugs.html
@@ -1,11 +1,10 @@
 
 
-Bugs
                    Bugs
                    Prev Chapter 1. Status Next
                    Bugs
                    Implementation Bugs
                    
+Bugs
                    Bugs
                    Prev Chapter 1. Status Next
                    Bugs
                    Implementation Bugs
                    
       Information on known bugs, details on efforts to fix them, and
-      fixed bugs are all available as part of the GCC bug tracking
-      system, bugzilla, with the
-      category set to libstdc++.
-    
                    Standard Bugs
                    
+      fixed bugs are all available as part of the GCC bug tracking system,
+      with the category set to libstdc++.
+    
                    Standard Bugs
                    
 	Everybody's got issues.  Even the C++ Standard Library.
       
                    
 	The Library Working Group, or LWG, is the ISO subcommittee responsible
@@ -248,7 +247,7 @@
     
                    409:
         Closing an fstream should clear the error state
     
                    Have open clear the error flags.
-    
                    431:
+    
                    431:
         Swapping containers with unequal allocators
     
                    Implement Option 3, as per N1599.
     
                    432:
@@ -286,6 +285,11 @@
 	    and Assignable?
     
                    In case of input_iterator/output_iterator rely on Assignability of
         input_iterator' value_type.
+    
                    539:
+        partial_sum and adjacent_difference should mention
+            requirements
+    
                    We were almost doing the right thing, just use std::move
+        in adjacent_difference.
     
                    541:
         shared_ptr template assignment and void
     
                    Add an auto_ptr<void> specialization.
@@ -301,7 +305,7 @@
     
                    596:
         27.8.1.3 Table 112 omits "a+" and "a+b" modes
     
                    Add the missing modes to fopen_mode.
-    
                    630:
+    
                    630:
         arrays of valarray
     
                    Implement the simple resolution.
     
                    660:
@@ -317,7 +321,7 @@
     
                    695:
         ctype<char>::classic_table() not accessible
     
                    Make the member functions table and classic_table public.
-    
                    696:
+    
                    696:
         istream::operator>>(int&) broken
     
                    Implement the straightforward resolution.
     
                    761:
@@ -341,4 +345,8 @@
     
                    853:
         to_string needs updating with zero and one
     
                    Update / add the signatures.
+    
                    865:
+        More algorithms that throw away information
+    
                    The traditional HP / SGI return type and value is blessed
+                    by the resolution of the DR.
     
                    Prev Up Next
                    License Home Chapter 2. Setup
                    
diff --git a/libstdc++-v3/doc/html/manual/codecvt.html b/libstdc++-v3/doc/html/manual/codecvt.html
index 0ac3285f1e9..93582a9765c 100644
--- a/libstdc++-v3/doc/html/manual/codecvt.html
+++ b/libstdc++-v3/doc/html/manual/codecvt.html
@@ -1,11 +1,11 @@
 
 
-codecvt
                    codecvt
                    Prev Chapter 15. Facets aka Categories Next
                    codecvt
                    
+codecvt
                    codecvt
                    Prev Chapter 15. Facets aka Categories Next
                    codecvt
                    
 The standard class codecvt attempts to address conversions between
 different character encoding schemes. In particular, the standard
 attempts to detail conversions between the implementation-defined wide
 characters (hereafter referred to as wchar_t) and the standard type
-char that is so beloved in classic “C” (which can now be
+char that is so beloved in classic “C” (which can now be
 referred to as narrow characters.)  This document attempts to describe
 how the GNU libstdc++ implementation deals with the conversion between
 wide and narrow characters, and also presents a framework for dealing
@@ -14,7 +14,7 @@ including Unicode and UTF8. Design issues and requirements are
 addressed, and examples of correct usage for both the required
 specializations for wide and narrow characters and the
 implementation-provided extended functionality are given.
-
                    Requirements
                    
+
                    Requirements
                    
 Around page 425 of the C++ Standard, this charming heading comes into view:
 
                    
 22.2.1.5 - Template class codecvt
@@ -60,7 +60,7 @@ third template parameter, stateT.
                    
 Two: The required conversions, by specifying mbstate_t as the third
 template parameter, imply an implementation strategy that is mostly
 (or wholly) based on the underlying C library, and the functions
-mcsrtombs and wcsrtombs in particular.
                    Design
                    wchar_t Size
                    
+mcsrtombs and wcsrtombs in particular.
                    Design
                    wchar_t Size
                    
       The simple implementation detail of wchar_t's size seems to
       repeatedly confound people. Many systems use a two byte,
       unsigned integral type to represent wide characters, and use an
@@ -72,7 +72,7 @@ mcsrtombs and wcsrtombs in particular.
                    
       Thus, portable C++ code cannot assume a byte size (or endianness) either.
-    
                    Support for Unicode
                    
+    
                    Support for Unicode
                    
     Probably the most frequently asked question about code conversion
     is: "So dudes, what's the deal with Unicode strings?"
     The dude part is optional, but apparently the usefulness of
@@ -89,7 +89,7 @@ mcsrtombs and wcsrtombs in particular.
                    • 
+  
                      • 
 	Identifiers for each of the codesets involved in the
 	conversion. For example, using the iconv family of functions
 	from the Single Unix Specification (what used to be called
@@ -115,32 +115,32 @@ encodings (i.e. "UCS-2" and "UTF-8") are necessary,
 although for other,
 non-iconv implementations a table of enumerated values or some other
 mechanism may be required.
-
                      • 
+
                      • 
  Maximum length of the identifying string literal.
-
                      • 
+
                      • 
  Some encodings require explicit endian-ness. As such, some kind
   of endian marker or other byte-order marker will be necessary. See
   "Footnotes for C/C++ developers" in Haible for more information on
   UCS-2/Unicode endian issues. (Summary: big endian seems most likely,
   however implementations, most notably Microsoft, vary.)
-
                      • 
+
                      • 
  Types representing the conversion state, for conversions involving
   the machinery in the "C" library, or the conversion descriptor, for
   conversions using iconv (such as the type iconv_t.)  Note that the
   conversion descriptor encodes more information than a simple encoding
   state type.
-
                      • 
+
                      • 
  Conversion descriptors for both directions of encoding. (i.e., both
   UCS-2 to UTF-8 and UTF-8 to UCS-2.)
-
                      • 
+
                      • 
  Something to indicate if the conversion requested if valid.
-
                      • 
+
                      • 
  Something to represent if the conversion descriptors are valid.
-
                      • 
+
                      • 
  Some way to enforce strict type checking on the internal and
   external types. As part of this, the size of the internal and
   external types will need to be known.
-
                    Other Issues
                    
+
                    Other Issues
                    
 In addition, multi-threaded and multi-locale environments also impact
 the design and requirements for code conversions. In particular, they
 affect the required specialization codecvt<wchar_t, char, mbstate_t>
@@ -172,7 +172,7 @@ For the required specialization codecvt<wchar_t, char, mbstate_t> ,
 conversions are made between the internal character set (always UCS4
 on GNU/Linux) and whatever the currently selected locale for the
 LC_CTYPE category implements.
-
                    Implementation
                    
+
                    Implementation
                    
 The two required specializations are implemented as follows:
 
                    
 
@@ -274,7 +274,7 @@ Definitions for all the required codecvt member functions are provided
 for this specialization, and usage of codecvt<internal character type,
 external character type, encoding_state> is consistent with other
 codecvt usage.
-
                    Use
                    A conversions involving string literal.
                    +
                    Use
                    A conversions involving string literal.
                       typedef codecvt_base::result                  result;
   typedef unsigned short                        unicode_t;
   typedef unicode_t                             int_type;
@@ -311,67 +311,67 @@ codecvt usage.
   VERIFY( !int_traits::compare(i_arr, i_lit, size) ); 
   VERIFY( efrom_next == e_lit + size );
   VERIFY( ito_next == i_arr + size );
-
                    Future
                    • 
+
                    Future
                    • 
    a. things that are sketchy, or remain unimplemented:
       do_encoding, max_length and length member functions
       are only weakly implemented. I have no idea how to do
       this correctly, and in a generic manner.  Nathan?
-
                    • 
+
                    • 
    b. conversions involving std::string
-  
                      • 
+  
                        • 
       how should operators != and == work for string of
       different/same encoding?
-      
                        • 
+      
                        • 
       what is equal? A byte by byte comparison or an
       encoding then byte comparison?
-      
                        • 
+      
                        • 
       conversions between narrow, wide, and unicode strings
-      
                      • 
+      
                    • 
    c. conversions involving std::filebuf and std::ostream
-
                      • 
+
                        • 
       how to initialize the state object in a
       standards-conformant manner?
-      
                        • 
+      
                        • 
       how to synchronize the "C" and "C++"
       conversion information?
-      
                        • 
+      
                        • 
       wchar_t/char internal buffers and conversions between
       internal/external buffers?
-      
                    Bibliography
                    
+      
                    Bibliography
                    
       The GNU C Library
-    . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization. 
                    
+    . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization. 
                    
       Correspondence
-    . Ulrich Drepper. Copyright © 2002 . 
                    
+    . Ulrich Drepper. Copyright © 2002 . 
                    
       ISO/IEC 14882:1998 Programming languages - C++
-    . Copyright © 1998 ISO. 
                    
+    . Copyright © 1998 ISO. 
                    
       ISO/IEC 9899:1999 Programming languages - C
-    . Copyright © 1999 ISO. 
                    
+    . Copyright © 1999 ISO. 
                    
       The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004)
     . Copyright © 1999 
       The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. 
       
       
-    . 
                    
+    . 
                    
       The C++ Programming Language, Special Edition
     . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. 
 	Addison Wesley
-      . 
                    
+      . 
                    
       Standard C++ IOStreams and Locales
     . 
       Advanced Programmer's Guide and Reference
     . Angelika Langer. Klaus Kreft. Copyright © 2000 Addison Wesley Longman, Inc.. 
 	Addison Wesley Longman
-      . 
                    
+      . 
                    
       A brief description of Normative Addendum 1
     . Clive Feather. Extended Character Sets. 
       
       
-    . 
                    
+    . 
                    
       The Unicode HOWTO
     . Bruno Haible. 
       
       
-    . 
                    
+    . 
                    
       UTF-8 and Unicode FAQ for Unix/Linux
     . Markus Khun. 
       
diff --git a/libstdc++-v3/doc/html/manual/complex.html b/libstdc++-v3/doc/html/manual/complex.html
index ac08c806093..cb82e609eab 100644
--- a/libstdc++-v3/doc/html/manual/complex.html
+++ b/libstdc++-v3/doc/html/manual/complex.html
@@ -1,10 +1,10 @@
 
 
-Chapter 21. Complex
                    Chapter 21. Complex
                    Prev Part X. 
+Chapter 21. Complex
                    Chapter 21. Complex
                    Prev Part X. 
   Numerics
   
- Next
                    Chapter 21. Complex
                    Table of Contents
                    complex Processing
                    
-  
                    complex Processing
                    
+
                    		 Next
                    Chapter 21. Complex
                    Table of Contents
                    complex Processing
                    
+  
                    complex Processing
                    
     
                    Using complex<> becomes even more comple- er, sorry,
       complicated, with the not-quite-gratuitously-incompatible
       addition of complex types to the C language.  David Tribble has
diff --git a/libstdc++-v3/doc/html/manual/configure.html b/libstdc++-v3/doc/html/manual/configure.html
index dce1c94e1eb..d7cde522e82 100644
--- a/libstdc++-v3/doc/html/manual/configure.html
+++ b/libstdc++-v3/doc/html/manual/configure.html
@@ -1,6 +1,6 @@
 
 
-Configure
                    Configure
                    Prev Chapter 2. Setup Next
                    Configure
                    
+Configure
                    Configure
                    Prev Chapter 2. Setup Next
                    Configure
                    
   When configuring libstdc++, you'll have to configure the entire
   gccsrcdir directory. Consider using the
   toplevel gcc configuration option
diff --git a/libstdc++-v3/doc/html/manual/containers.html b/libstdc++-v3/doc/html/manual/containers.html
index 9fc6bcdab56..e198f77a440 100644
--- a/libstdc++-v3/doc/html/manual/containers.html
+++ b/libstdc++-v3/doc/html/manual/containers.html
@@ -1,9 +1,9 @@
 
 
-Part VII.  Containers
                    Part VII. 
+Part VII.  Containers
                    Part VII. 
   Containers
   
-
                    Prev The GNU C++ Library Next
                    Part VII. 
+
                    Prev The GNU C++ Library Next
                    Part VII. 
   Containers
-  
+  
 
                    Table of Contents
                    16. Sequences
                    list
                    list::size() is O(n)
                    vector
                    Space Overhead Management
                    17. Associative
                    Insertion Hints
                    bitset
                    Size Variable
                    Type String
                    18. Interacting with C
                    Containers vs. Arrays
                    Prev Up Next
                    messages Home Chapter 16. Sequences
                    
diff --git a/libstdc++-v3/doc/html/manual/containers_and_c.html b/libstdc++-v3/doc/html/manual/containers_and_c.html
index 1ea55b3cfd3..3f658590f44 100644
--- a/libstdc++-v3/doc/html/manual/containers_and_c.html
+++ b/libstdc++-v3/doc/html/manual/containers_and_c.html
@@ -1,9 +1,9 @@
 
 
-Chapter 18. Interacting with C
                    Chapter 18. Interacting with C
                    Prev Part VII. 
+Chapter 18. Interacting with C
                    Chapter 18. Interacting with C
                    Prev Part VII. 
   Containers
   
- Next
                    Chapter 18. Interacting with C
                    Table of Contents
                    Containers vs. Arrays
                    Containers vs. Arrays
                    
+
                    		 Next
                    Chapter 18. Interacting with C
                    Table of Contents
                    Containers vs. Arrays
                    Containers vs. Arrays
                    
      You're writing some code and can't decide whether to use builtin
      arrays or some kind of container.  There are compelling reasons
      to use one of the container classes, but you're afraid that
@@ -13,7 +13,7 @@
    
                    
      If your code makes use of the standard algorithms, this isn't as
      scary as it sounds.  The algorithms don't know, nor care, about
-     the kind of “container” on which they work, since
+     the kind of “container” on which they work, since
      the algorithms are only given endpoints to work with.  For the
      container classes, these are iterators (usually
      begin() and end(), but not always).
diff --git a/libstdc++-v3/doc/html/manual/debug.html b/libstdc++-v3/doc/html/manual/debug.html
index d1a4fb2232b..e05fb66b802 100644
--- a/libstdc++-v3/doc/html/manual/debug.html
+++ b/libstdc++-v3/doc/html/manual/debug.html
@@ -1,10 +1,10 @@
 
 
-Debugging Support
                    Debugging Support
                    Prev Chapter 3. Using Next
                    Debugging Support
                    
+Debugging Support
                    Debugging Support
                    Prev Chapter 3. Using Next
                    Debugging Support
                    
   There are numerous things that can be done to improve the ease with
   which C++ binaries are debugged when using the GNU tool chain. Here
   are some of them.
-
                    Using g++
                     
+
                    Using g++
                     
     Compiler flags determine how debug information is transmitted
     between compilation and debug or analysis tools.
   
                    
@@ -31,7 +31,7 @@
   Many other options are available: please see "Options
   for Debugging Your Program" in Using the GNU Compiler
   Collection (GCC) for a complete list.
-
                    Debug Versions of Library Binary Files
                    
+
                    Debug Versions of Library Binary Files
                    
   If you would like debug symbols in libstdc++, there are two ways to
   build libstdc++ with debug flags. The first is to run make from the
   toplevel in a freshly-configured tree with
@@ -52,7 +52,7 @@
 
                    
   This quick and dirty approach is often sufficient for quick
   debugging tasks, when you cannot or don't want to recompile your
-  application to use the debug mode.
                    Memory Leak Hunting
                    
+  application to use the debug mode.
                    Memory Leak Hunting
                    
   There are various third party memory tracing and debug utilities
   that can be used to provide detailed memory allocation information
   about C++ code. An exhaustive list of tools is not going to be
@@ -121,7 +121,7 @@
   up the runtime environment, library, and test file, might be:
 
                     
    valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
-
                    Using gdb
                     
+
                    Using gdb
                     
   
                    
   Many options are available for gdb itself: please see 
   "GDB features for C++"  in the gdb documentation. Also
@@ -174,16 +174,16 @@
   on-line versions of the GDB user manual in GDB's homepage, at
    "GDB: The GNU Project
   Debugger" .
-
                    Tracking uncaught exceptions
                    
+
                    Tracking uncaught exceptions
                    
   The verbose
   termination handler gives information about uncaught
   exceptions which are killing the program.  It is described in the
   linked-to page.
-
                    Debug Mode
                     The Debug Mode
+
                    Debug Mode
                     The Debug Mode
   has compile and run-time checks for many containers.
-  
                    Compile Time Checking
                     The Compile-Time
+  
                    Compile Time Checking
                     The Compile-Time
   Checks Extension has compile-time checks for many algorithms.
-  
                    Profile-based Performance Analysis
                     The Profile-based 
+  
                    Profile-based Performance Analysis
                     The Profile-based 
   Performance Analysis Extension has performance checks for many 
   algorithms.
   
                    Prev Up Next
                    Exceptions Home Part II. 
diff --git a/libstdc++-v3/doc/html/manual/debug_mode.html b/libstdc++-v3/doc/html/manual/debug_mode.html
index bebd380b89b..9231ca944b7 100644
--- a/libstdc++-v3/doc/html/manual/debug_mode.html
+++ b/libstdc++-v3/doc/html/manual/debug_mode.html
@@ -1,9 +1,9 @@
 
 
-Chapter 30. Debug Mode
                    Chapter 30. Debug Mode
                    Prev Part XII. 
+Chapter 30. Debug Mode
                    Chapter 30. Debug Mode
                    Prev Part XII. 
   Extensions
   
- Next
                    Chapter 30. Debug Mode
                    Table of Contents
                    Intro
                    Semantics
                    Using
                    Using the Debug Mode
                    Using a Specific Debug Container
                    Design
                    Goals
                    Methods
                    Other Implementations
                    Intro
                    
+
                    		 Next
                    Chapter 30. Debug Mode
                    Table of Contents
                    Intro
                    Semantics
                    Using
                    Using the Debug Mode
                    Using a Specific Debug Container
                    Design
                    Goals
                    Methods
                    Other Implementations
                    Intro
                    
     By default, libstdc++ is built with efficiency in mind, and
     therefore performs little or no error checking that is not
     required by the C++ standard. This means that programs that
@@ -20,11 +20,11 @@
     The libstdc++ debug mode performs checking for many areas of the
     C++ standard, but the focus is on checking interactions among
     standard iterators, containers, and algorithms, including:
-  
                    • Safe iterators: Iterators keep track of the
+  
                      • Safe iterators: Iterators keep track of the
     container whose elements they reference, so errors such as
     incrementing a past-the-end iterator or dereferencing an iterator
     that points to a container that has been destructed are diagnosed
-    immediately.
                      • Algorithm preconditions: Algorithms attempt to
+    immediately.
                      • Algorithm preconditions: Algorithms attempt to
     validate their input parameters to detect errors as early as
     possible. For instance, the set_intersection
     algorithm requires that its iterator
diff --git a/libstdc++-v3/doc/html/manual/diagnostics.html b/libstdc++-v3/doc/html/manual/diagnostics.html
index b869aec22f8..1e6746ac5ea 100644
--- a/libstdc++-v3/doc/html/manual/diagnostics.html
+++ b/libstdc++-v3/doc/html/manual/diagnostics.html
@@ -1,9 +1,9 @@
 
 
-Part III.  Diagnostics
                        Part III. 
+Part III.  Diagnostics
                        Part III. 
   Diagnostics
   
-
                        Prev The GNU C++ Library Next
                        Part III. 
+
                        Prev The GNU C++ Library Next
                        Part III. 
   Diagnostics
-  
+  
 
                        Table of Contents
                        7. Exceptions
                        Exception Classes
                        Adding Data to Exceptions
                        8. Concept Checking
                        Prev Up Next
                        Verbose Terminate Handler Home Chapter 7. Exceptions
                        
diff --git a/libstdc++-v3/doc/html/manual/documentation_style.html b/libstdc++-v3/doc/html/manual/documentation_style.html
index e8d7831cb5c..6cb74dce14c 100644
--- a/libstdc++-v3/doc/html/manual/documentation_style.html
+++ b/libstdc++-v3/doc/html/manual/documentation_style.html
@@ -1,9 +1,9 @@
 
 
-Documentation Style
                        Documentation Style
                        Prev Appendix A. 
+Documentation Style
                        Documentation Style
                        Prev Appendix A. 
   Contributing
   
- Next
                        Documentation Style
                        Doxygen
                        Prerequisites
                        
+
                        		 Next
                        Documentation Style
                        Doxygen
                        Prerequisites
                        
 	Prerequisite tools are Bash 2.x,
 	Doxygen, and
 	the GNU
@@ -15,7 +15,7 @@
 	graphs, the
 	Graphviz
 	package will need to be installed. 
-      
                        Generating the Doxygen Files
                        
+      
                        Generating the Doxygen Files
                        
 	The following Makefile rules run Doxygen to generate HTML
 	docs, XML docs, and the man pages.
       
                        
@@ -35,7 +35,7 @@
 	If you wish to tweak the Doxygen settings, do so by editing
 	doc/doxygen/user.cfg.in. Notes to fellow
 	library hackers are written in triple-# comments.
-      
                        Markup
                        
+      
                        Markup
                        
 	In general, libstdc++ files should be formatted according to
 	the rules found in the
 	Coding Standard. Before
@@ -43,7 +43,7 @@
 	make sure that the initial formatting is sound.
       
                        
 	Adding Doxygen markup to a file (informally called
-	“doxygenating”) is very simple. The Doxygen manual can be
+	“doxygenating”) is very simple. The Doxygen manual can be
 	found
 	here.
 	We try to use a very-recent version of Doxygen.
@@ -58,14 +58,14 @@
       
                        
 	These points accompany the first list in section 3.1 of the
 	Doxygen manual:
-      
                        1. Use the Javadoc style...
                        2. 
+      
                          1. Use the Javadoc style...
                          2. 
 	    ...not the Qt style. The intermediate *'s are preferred.
-	  
                          3. 
+	  
                          4. 
 	    Use the triple-slash style only for one-line comments (the
-	    “brief” mode).  Very recent versions of Doxygen permit
+	    “brief” mode).  Very recent versions of Doxygen permit
 	    full-mode comments in triple-slash blocks, but the
 	    formatting still comes out wonky.
-	  
                          5. 
+	  
                          6. 
 	    This is disgusting. Don't do this.
 	  
                          
 	Use the @-style of commands, not the !-style. Please be
@@ -73,24 +73,24 @@
 	time it doesn't matter; doxygen absorbs most whitespace, and
 	both HTML and *roff are agnostic about whitespace. However,
 	in <pre> blocks and @code/@endcode sections, spacing can
-	have “interesting” effects.
+	have “interesting” effects.
       
                          
 	Use either kind of grouping, as
 	appropriate. doxygroups.cc exists for this
 	purpose. See stl_iterator.h for a good example
-	of the “other” kind of grouping.
+	of the “other” kind of grouping.
       
                          
 	Please use markup tags like @p and @a when referring to things
 	such as the names of function parameters. Use @e for emphasis
 	when necessary. Use @c to refer to other standard names.
 	(Examples of all these abound in the present code.)
-      
                        Docbook
                        Prerequisites
                        
+      
                        Docbook
                        Prerequisites
                        
 	Editing the DocBook sources requires an XML editor. Many
 	exist: some notable options
 	include emacs, Kate,
 	or Conglomerate.
       
                        
-	Some editors support special “XML Validation”
+	Some editors support special “XML Validation”
 	modes that can validate the file as it is
 	produced. Recommended is the nXML Mode
 	for emacs.
@@ -133,7 +133,7 @@
 	  
 xmllint --noout --valid xml/index.xml
 	  
-	
                        Generating the DocBook Files
                        
+	
                        Generating the DocBook Files
                        
 	The following Makefile rules generate (in order): an HTML
 	version of all the documentation, a PDF version of the same, a
 	single XML document, and the result of validating the entire XML
@@ -146,7 +146,7 @@ xmllint --noout --valid xml/index.xml
       
                        make doc-xml-single
                        
       
                        
       
                        make doc-xml-validate
                        
-      
                        File Organization and Basics

                        
+      
                        File Organization and Basics

                        
       Which files are important
                        
 
                        
       All Docbook files are in the directory
                        
@@ -206,16 +206,16 @@ xmllint --noout --valid xml/index.xml
       </book>
                        
 
                        
       </set>
                        
-    
                        Markup By Example
                        
+    
                        Markup By Example
                        
 Complete details on Docbook markup can be found in the DocBook Element
 Reference, online. An
 incomplete reference for HTML to Docbook conversion is detailed in the
 table below.
-
                        Table A.1. HTML to Docbook XML markup comparison
                        HTMLXML
                        <p><para>
                        <pre><computeroutput>, <programlisting>, 
+
                        Table A.1. HTML to Docbook XML markup comparison
                        HTMLXML
                        <p><para>
                        <pre><computeroutput>, <programlisting>, 
 	<literallayout>
                        <ul><itemizedlist>
                        <ol><orderedlist>
                        <il><listitem>
                        <dl><variablelist>
                        <dt><term>
                        <dd><listitem>
                        <a href=""><ulink url="">
                        <code><literal>, <programlisting>
                        <strong><emphasis>
                        <em><emphasis>
                        "<quote>

                        
   And examples of detailed markup for which there are no real HTML
   equivalents are listed in the table below.
-
                        Table A.2. Docbook XML Element Use
                        ElementUse
                        <structname><structname>char_traits</structname>
                        <classname><classname>string</classname>
                        <function>
+
                        Table A.2. Docbook XML Element Use
                        ElementUse
                        <structname><structname>char_traits</structname>
                        <classname><classname>string</classname>
                        <function>
 	
                        <function>clear()</function>
                        
 	
                        <function>fs.clear()</function>
                        
       
                        <type><type>long long</type>
                        <varname><varname>fs</varname>
                        <literal>
diff --git a/libstdc++-v3/doc/html/manual/dynamic_memory.html b/libstdc++-v3/doc/html/manual/dynamic_memory.html
index 0779d6cc247..e23fdf5c272 100644
--- a/libstdc++-v3/doc/html/manual/dynamic_memory.html
+++ b/libstdc++-v3/doc/html/manual/dynamic_memory.html
@@ -1,28 +1,28 @@
 
 
-Chapter 5. Dynamic Memory
                        Chapter 5. Dynamic Memory
                        Prev Part II. 
+Chapter 5. Dynamic Memory
                        Chapter 5. Dynamic Memory
                        Prev Part II. 
   Support
   
- Next
                        Chapter 5. Dynamic Memory
                        
+
                        		 Next
                        Chapter 5. Dynamic Memory
                        
     There are six flavors each of new and
     delete, so make certain that you're using the right
     ones. Here are quickie descriptions of new:
-  
                        • 
+  
                          • 
 	single object form, throwing a
 	bad_alloc on errors; this is what most
 	people are used to using
-      
                          • 
+      
                          • 
 	Single object "nothrow" form, returning NULL on errors
-      
                          • 
+      
                          • 
 	Array new, throwing
 	bad_alloc on errors
-      
                          • 
+      
                          • 
 	Array nothrow new, returning
 	NULL on errors
-      
                          • 
+      
                          • 
 	Placement new, which does nothing (like
 	it's supposed to)
-      
                          • 
+      
                          • 
 	Placement array new, which also does
 	nothing
       
                          
@@ -36,7 +36,7 @@
      NULL pointer!  Nothing happens, by definition.  That is not the
      same thing as deleting a pointer twice.
    
                          
-     By default, if one of the “throwing news” can't
+     By default, if one of the “throwing news” can't
      allocate the memory requested, it tosses an instance of a
      bad_alloc exception (or, technically, some class derived
      from it).  You can change this by writing your own function (called a
diff --git a/libstdc++-v3/doc/html/manual/exceptions.html b/libstdc++-v3/doc/html/manual/exceptions.html
index 83eb8892fa4..572bee01af5 100644
--- a/libstdc++-v3/doc/html/manual/exceptions.html
+++ b/libstdc++-v3/doc/html/manual/exceptions.html
@@ -1,9 +1,9 @@
 
 
-Chapter 7. Exceptions
                          Chapter 7. Exceptions
                          Prev Part III. 
+Chapter 7. Exceptions
                          Chapter 7. Exceptions
                          Prev Part III. 
   Diagnostics
   
- Next
                          Chapter 7. Exceptions
                          Table of Contents
                          Exception Classes
                          Adding Data to Exceptions
                          Exception Classes
                          
+
                          		 Next
                          Chapter 7. Exceptions
                          Table of Contents
                          Exception Classes
                          Adding Data to Exceptions
                          Exception Classes
                          
       All exception objects are defined in one of the standard header
       files: exception,
       stdexcept, new, and
diff --git a/libstdc++-v3/doc/html/manual/ext_algorithms.html b/libstdc++-v3/doc/html/manual/ext_algorithms.html
index eadb4441b1e..02231d43e4d 100644
--- a/libstdc++-v3/doc/html/manual/ext_algorithms.html
+++ b/libstdc++-v3/doc/html/manual/ext_algorithms.html
@@ -1,9 +1,9 @@
 
 
-Chapter 36. Algorithms
                          Chapter 36. Algorithms
                          Prev Part XII. 
+Chapter 36. Algorithms
                          Chapter 36. Algorithms
                          Prev Part XII. 
   Extensions
   
- Next
                          Chapter 36. Algorithms
                          25.1.6 (count, count_if) is extended with two more versions of count
+
                          		 Next
                          Chapter 36. Algorithms
                          25.1.6 (count, count_if) is extended with two more versions of count
    and count_if.  The standard versions return their results.  The
    additional signatures return void, but take a final parameter by
    reference to which they assign their results, e.g.,
@@ -15,7 +15,7 @@
    copy_n (_InputIter first, _Size count, _OutputIter result);
                          which copies the first 'count' elements at 'first' into 'result'.
 
                          25.3 (sorting 'n' heaps 'n' stuff) is extended with some helper
    predicates.  Look in the doxygen-generated pages for notes on these.
-
                          • is_heap tests whether or not a range is a heap.
                          • is_sorted tests whether or not a range is sorted in
+
                            • is_heap tests whether or not a range is a heap.
                            • is_sorted tests whether or not a range is sorted in
         nondescending order.
                            25.3.8 (lexicographical_compare) is extended with
 
                                lexicographical_compare_3way(_InputIter1 first1, _InputIter1 last1,
diff --git a/libstdc++-v3/doc/html/manual/ext_allocators.html b/libstdc++-v3/doc/html/manual/ext_allocators.html
index cec9f8228a0..d1af7e13639 100644
--- a/libstdc++-v3/doc/html/manual/ext_allocators.html
+++ b/libstdc++-v3/doc/html/manual/ext_allocators.html
@@ -1,10 +1,10 @@
 
 
-Chapter 33. Allocators
                            Chapter 33. Allocators
                            Prev Part XII. 
+Chapter 33. Allocators
                            Chapter 33. Allocators
                            Prev Part XII. 
   Extensions
   
- Next
                            Chapter 33. Allocators
                            Table of Contents
                            mt_allocator
                            Intro
                            Design Issues
                            Implementation
                            Single Thread Example
                            Multiple Thread Example
                            bitmap_allocator
                            Design
                            Implementation
                            mt_allocator
                            
-
                            Intro
                             
+
                            		 Next
                            Chapter 33. Allocators
                            Table of Contents
                            mt_allocator
                            Intro
                            Design Issues
                            Implementation
                            Single Thread Example
                            Multiple Thread Example
                            bitmap_allocator
                            Design
                            Implementation
                            mt_allocator
                            
+
                            Intro
                             
   The mt allocator [hereinafter referred to simply as "the allocator"]
   is a fixed size (power of two) allocator that was initially
   developed specifically to suit the needs of multi threaded
@@ -20,7 +20,7 @@
 
                            
   The aim of this document is to describe - from an application point of
   view - the "inner workings" of the allocator.
-
                            Design Issues
                            Overview
                             There are three general components to the allocator: a datum
+
                            Design Issues
                            Overview
                             There are three general components to the allocator: a datum
 describing the characteristics of the memory pool, a policy class
 containing this pool that links instantiation types to common or
 individual pools, and a class inheriting from the policy class that is
@@ -56,10 +56,10 @@ tuning, for instance.
 
                             This class has the interface required for standard library allocator
 classes, namely member functions allocate and
 deallocate, plus others.
-
                          Implementation
                          Tunable Parameters
                          Certain allocation parameters can be modified, or tuned. There
+
                          Implementation
                          Tunable Parameters
                          Certain allocation parameters can be modified, or tuned. There
 exists a nested struct __pool_base::_Tune that contains all
 these parameters, which include settings for
-
                          • Alignment
                          • Maximum bytes before calling ::operator new directly
                          • Minimum bytes
                          • Size of underlying global allocations
                          • Maximum number of supported threads
                          • Migration of deallocations to the global free list
                          • Shunt for global new and delete
                          Adjusting parameters for a given instance of an allocator can only
+
                          • Alignment
                          • Maximum bytes before calling ::operator new directly
                          • Minimum bytes
                          • Size of underlying global allocations
                          • Maximum number of supported threads
                          • Migration of deallocations to the global free list
                          • Shunt for global new and delete
                          Adjusting parameters for a given instance of an allocator can only
 happen before any allocations take place, when the allocator itself is
 initialized. For instance:
 
                          @@ -95,7 +95,7 @@ int main()
 
   return 0;
 }
-
                          Initialization
                          
+
                          Initialization
                          
 The static variables (pointers to freelists, tuning parameters etc)
 are initialized as above, or are set to the global defaults.
 
                          
@@ -187,7 +187,7 @@ The _S_initialize() function:
     for this specific bin. This only occurs when a number of blocks
     are grabbed from the global list to a thread specific list or when
     a thread decides to return some blocks to the global freelist.
-
                          Deallocation Notes
                           Notes about deallocation. This allocator does not explicitly
+
                          Deallocation Notes
                           Notes about deallocation. This allocator does not explicitly
 release memory. Because of this, memory debugging programs like
 valgrind or purify may notice leaks: sorry about this
 inconvenience. Operating systems will reclaim allocated memory at
@@ -214,7 +214,7 @@ implementation-specific, and subject to change. For an example of a
 pool that frees memory, see the following
     
     example.
-
                          Single Thread Example
                          
+
                          Single Thread Example
                          
 Let's start by describing how the data on a freelist is laid out in memory.
 This is the first two blocks in freelist for thread id 3 in bin 3 (8 bytes):
 
                          @@ -290,7 +290,7 @@ of the global freelist and update the pointer as needed
 The decision to add deallocated blocks to the front of the freelist was made
 after a set of performance measurements that showed that this is roughly 10%
 faster than maintaining a set of "last pointers" as well.
-
                          Multiple Thread Example
                          
+
                          Multiple Thread Example
                          
 In the ST example we never used the thread_id variable present in each block. 
 Let's start by explaining the purpose of this in a MT application. 
 
                          
diff --git a/libstdc++-v3/doc/html/manual/ext_compile_checks.html b/libstdc++-v3/doc/html/manual/ext_compile_checks.html
index fa438da43de..104d81a9908 100644
--- a/libstdc++-v3/doc/html/manual/ext_compile_checks.html
+++ b/libstdc++-v3/doc/html/manual/ext_compile_checks.html
@@ -1,16 +1,16 @@
 
 
-Chapter 29. Compile Time Checks
                          Chapter 29. Compile Time Checks
                          Prev Part XII. 
+Chapter 29. Compile Time Checks
                          Chapter 29. Compile Time Checks
                          Prev Part XII. 
   Extensions
   
- Next
                          Chapter 29. Compile Time Checks
                          
+
                          		 Next
                          Chapter 29. Compile Time Checks
                          
     Also known as concept checking.
   
                          In 1999, SGI added concept checkers to their implementation
       of the STL:  code which checked the template parameters of
       instantiated pieces of the STL, in order to insure that the parameters
       being used met the requirements of the standard.  For example,
       the Standard requires that types passed as template parameters to
-      vector be “Assignable” (which means what you think
+      vector be “Assignable” (which means what you think
       it means).  The checking was done during compilation, and none of
       the code was executed at runtime.
    
                          Unfortunately, the size of the compiler files grew significantly
diff --git a/libstdc++-v3/doc/html/manual/ext_concurrency.html b/libstdc++-v3/doc/html/manual/ext_concurrency.html
index 9fa8f74d7b1..0d660c7402c 100644
--- a/libstdc++-v3/doc/html/manual/ext_concurrency.html
+++ b/libstdc++-v3/doc/html/manual/ext_concurrency.html
@@ -1,9 +1,9 @@
 
 
-Chapter 41. Concurrency
                          Chapter 41. Concurrency
                          Prev Part XII. 
+Chapter 41. Concurrency
                          Chapter 41. Concurrency
                          Prev Part XII. 
   Extensions
   
- Next
                          Chapter 41. Concurrency
                          Table of Contents
                          Design
                          Interface to Locks and Mutexes
                          Interface to Atomic Functions
                          Implementation
                          Using Builtin Atomic Functions
                          Thread Abstraction
                          Use
                          Design
                          Interface to Locks and Mutexes
                          The file <ext/concurrence.h> contains all the higher-level
+
                          		 Next
                          Chapter 41. Concurrency
                          Table of Contents
                          Design
                          Interface to Locks and Mutexes
                          Interface to Atomic Functions
                          Implementation
                          Using Builtin Atomic Functions
                          Thread Abstraction
                          Use
                          Design
                          Interface to Locks and Mutexes
                          The file <ext/concurrence.h> contains all the higher-level
 constructs for playing with threads. In contrast to the atomics layer,
 the concurrence layer consists largely of types. All types are defined within namespace __gnu_cxx.
 
                          
@@ -16,9 +16,9 @@ that support multiple threads.)
 available locking
 policies: _S_single, _S_mutex,
 and _S_atomic.
-
                          • _S_single
                            Indicates single-threaded code that does not need locking.
-
                          • _S_mutex
                            Indicates multi-threaded code using thread-layer abstractions.
-
                          • _S_atomic
                            Indicates multi-threaded code using atomic operations.
+
                            • _S_single
                              Indicates single-threaded code that does not need locking.
+
                            • _S_mutex
                              Indicates multi-threaded code using thread-layer abstractions.
+
                            • _S_atomic
                              Indicates multi-threaded code using atomic operations.
 
                            The compile-time constant __default_lock_policy is set
 to one of the three values above, depending on characteristics of the
 host environment and the current compilation flags.
@@ -30,7 +30,7 @@ community. This version takes a __mutex reference, and
 locks it during construction of __scoped_locke and
 unlocks it during destruction. This is an efficient way of locking
 critical sections, while retaining exception-safety.
-
                          Interface to Atomic Functions
                          
+
                          Interface to Atomic Functions
                          
 Two functions and one type form the base of atomic support. 
 
                          The type _Atomic_word is a signed integral type
 supporting atomic operations.
@@ -44,12 +44,12 @@ void
 __atomic_add_dispatch(volatile _Atomic_word*, int);
 
                          Both of these functions are declared in the header file
 <ext/atomicity.h>, and are in namespace __gnu_cxx.
-
                          • 
+
                            • 
 
 __exchange_and_add_dispatch
 
 
                              Adds the second argument's value to the first argument. Returns the old value.
-
                            • 
+
                            • 
 
 __atomic_add_dispatch
 
@@ -63,11 +63,11 @@ __exchange_and_add_dispatch
 
 
                              
 Calls through to either of:
-
                              • __exchange_and_add
+
                                • __exchange_and_add
 
                                  Multi-thread version. Inlined if compiler-generated builtin atomics
 can be used, otherwise resolved at link time to a non-builtin code
 sequence.
-
                                • __exchange_and_add_single 
+
                                • __exchange_and_add_single 
 
                                  Single threaded version. Inlined.
                                However, only __exchange_and_add_dispatch
 and __atomic_add_dispatch should be used. These functions
 can be used in a portable manner, regardless of the specific
diff --git a/libstdc++-v3/doc/html/manual/ext_containers.html b/libstdc++-v3/doc/html/manual/ext_containers.html
index 47ada7b5db6..5b767d27922 100644
--- a/libstdc++-v3/doc/html/manual/ext_containers.html
+++ b/libstdc++-v3/doc/html/manual/ext_containers.html
@@ -1,9 +1,9 @@
 
 
-Chapter 34. Containers
                                Chapter 34. Containers
                                Prev Part XII. 
+Chapter 34. Containers
                                Chapter 34. Containers
                                Prev Part XII. 
   Extensions
   
- Next
                                Chapter 34. Containers
                                Table of Contents
                                Policy Based Data Structures
                                HP/SGI
                                Deprecated HP/SGI
                                
-  
                                Policy Based Data Structures
                                
+
                                		 Next
                                Chapter 34. Containers
                                Table of Contents
                                Policy Based Data Structures
                                HP/SGI
                                Deprecated HP/SGI
                                
+  
                                Policy Based Data Structures
                                
       More details here.
     
                                Prev Up Next
                                bitmap_allocator Home HP/SGI
                                
diff --git a/libstdc++-v3/doc/html/manual/ext_demangling.html b/libstdc++-v3/doc/html/manual/ext_demangling.html
index 46866b82bf9..8952d5718d8 100644
--- a/libstdc++-v3/doc/html/manual/ext_demangling.html
+++ b/libstdc++-v3/doc/html/manual/ext_demangling.html
@@ -1,12 +1,12 @@
 
 
-Chapter 40. Demangling
                                Chapter 40. Demangling
                                Prev Part XII. 
+Chapter 40. Demangling
                                Chapter 40. Demangling
                                Prev Part XII. 
   Extensions
   
- Next
                                Chapter 40. Demangling
                                
+
                                		 Next
                                Chapter 40. Demangling
                                
     Transforming C++ ABI identifiers (like RTTI symbols) into the
     original C++ source identifiers is called
-    “demangling.”
+    “demangling.”
   
                                
     If you have read the source
     documentation for namespace abi then you are
diff --git a/libstdc++-v3/doc/html/manual/ext_io.html b/libstdc++-v3/doc/html/manual/ext_io.html
index d257c2c51e5..796c311f3e6 100644
--- a/libstdc++-v3/doc/html/manual/ext_io.html
+++ b/libstdc++-v3/doc/html/manual/ext_io.html
@@ -1,41 +1,41 @@
 
 
-Chapter 39. Input and Output
                                Chapter 39. Input and Output
                                Prev Part XII. 
+Chapter 39. Input and Output
                                Chapter 39. Input and Output
                                Prev Part XII. 
   Extensions
   
- Next
                                Chapter 39. Input and Output
                                Table of Contents
                                Derived filebufs
                                
+
                                		 Next
                                Chapter 39. Input and Output
                                Table of Contents
                                Derived filebufs
                                
     Extensions allowing filebufs to be constructed from
     "C" types like  FILE*s and file descriptors.
-  
                                Derived filebufs
                                The v2 library included non-standard extensions to construct
+  
                                Derived filebufs
                                The v2 library included non-standard extensions to construct
       std::filebufs from C stdio types such as
       FILE*s and POSIX file descriptors.
       Today the recommended way to use stdio types with libstdc++
       IOStreams is via the stdio_filebuf class (see below),
       but earlier releases provided slightly different mechanisms.
-   
                                • 3.0.x filebufs have another ctor with this signature:
+   
                                  • 3.0.x filebufs have another ctor with this signature:
         basic_filebuf(__c_file_type*, ios_base::openmode, int_type);
 	
          This comes in very handy in a number of places, such as
          attaching Unix sockets, pipes, and anything else which uses file
          descriptors, into the IOStream buffering classes.  The three
          arguments are as follows:
-         
                                    • __c_file_type*      F   
+         
                                      • __c_file_type*      F   
               // the __c_file_type typedef usually boils down to stdio's FILE
-          
                                      • ios_base::openmode  M   
+          
                                      • ios_base::openmode  M   
               // same as all the other uses of openmode
-          
                                      • int_type            B   
+          
                                      • int_type            B   
               // buffer size, defaults to BUFSIZ if not specified
           
                                      
          For those wanting to use file descriptors instead of FILE*'s, I
          invite you to contemplate the mysteries of C's fdopen().
-     
                                    • In library snapshot 3.0.95 and later, filebufs bring
+     
                                    • In library snapshot 3.0.95 and later, filebufs bring
          back an old extension:  the fd() member function.  The
          integer returned from this function can be used for whatever file
          descriptors can be used for on your platform.  Naturally, the
          library cannot track what you do on your own with a file descriptor,
          so if you perform any I/O directly, don't expect the library to be
          aware of it.
-     
                                    • Beginning with 3.1, the extra filebuf constructor and
+     
                                    • Beginning with 3.1, the extra filebuf constructor and
          the fd() function were removed from the standard
          filebuf.  Instead, <ext/stdio_filebuf.h> contains
          a derived class called
diff --git a/libstdc++-v3/doc/html/manual/ext_iterators.html b/libstdc++-v3/doc/html/manual/ext_iterators.html
index 20be5ac7831..88259a8ace9 100644
--- a/libstdc++-v3/doc/html/manual/ext_iterators.html
+++ b/libstdc++-v3/doc/html/manual/ext_iterators.html
@@ -1,13 +1,13 @@
 
 
-Chapter 38. Iterators
                                      Chapter 38. Iterators
                                      Prev Part XII. 
+Chapter 38. Iterators
                                      Chapter 38. Iterators
                                      Prev Part XII. 
   Extensions
   
- Next
                                      Chapter 38. Iterators
                                      24.3.2 describes struct iterator, which didn't exist in the
+
                                      		 Next
                                      Chapter 38. Iterators
                                      24.3.2 describes struct iterator, which didn't exist in the
    original HP STL implementation (the language wasn't rich enough at the
    time).  For backwards compatibility, base classes are provided which
    declare the same nested typedefs:
-
                                      • input_iterator
                                      • output_iterator
                                      • forward_iterator
                                      • bidirectional_iterator
                                      • random_access_iterator
                                      24.3.4 describes iterator operation distance, which takes
+
                                      • input_iterator
                                      • output_iterator
                                      • forward_iterator
                                      • bidirectional_iterator
                                      • random_access_iterator
                                      24.3.4 describes iterator operation distance, which takes
    two iterators and returns a result.  It is extended by another signature
    which takes two iterators and a reference to a result.  The result is
    modified, and the function returns nothing.
diff --git a/libstdc++-v3/doc/html/manual/ext_numerics.html b/libstdc++-v3/doc/html/manual/ext_numerics.html
index dc47b617dbf..e8f86678a7c 100644
--- a/libstdc++-v3/doc/html/manual/ext_numerics.html
+++ b/libstdc++-v3/doc/html/manual/ext_numerics.html
@@ -1,9 +1,9 @@
 
 
-Chapter 37. Numerics
                                      Chapter 37. Numerics
                                      Prev Part XII. 
+Chapter 37. Numerics
                                      Chapter 37. Numerics
                                      Prev Part XII. 
   Extensions
   
- Next
                                      Chapter 37. Numerics
                                      26.4, the generalized numeric operations such as accumulate, are extended
+
                                      		 Next
                                      Chapter 37. Numerics
                                      26.4, the generalized numeric operations such as accumulate, are extended
    with the following functions:
 
                                          power (x, n);
diff --git a/libstdc++-v3/doc/html/manual/ext_utilities.html b/libstdc++-v3/doc/html/manual/ext_utilities.html
index cf475c6f064..2685de374b9 100644
--- a/libstdc++-v3/doc/html/manual/ext_utilities.html
+++ b/libstdc++-v3/doc/html/manual/ext_utilities.html
@@ -1,23 +1,23 @@
 
 
-Chapter 35. Utilities
                                      Chapter 35. Utilities
                                      Prev Part XII. 
+Chapter 35. Utilities
                                      Chapter 35. Utilities
                                      Prev Part XII. 
   Extensions
   
- Next
                                      Chapter 35. Utilities
                                      
+
                                      		 Next
                                      Chapter 35. Utilities
                                      
     The <functional> header contains many additional functors
     and helper functions, extending section 20.3.  They are
     implemented in the file stl_function.h:
-  
                                      Bibliography
                                      
       The GNU C Library
-    . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6  Character Set Handling and 7 Locales and Internationalization. 
                                      
+    . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6  Character Set Handling and 7 Locales and Internationalization. 
                                      
       Correspondence
-    . Ulrich Drepper. Copyright © 2002 . 
                                      
+    . Ulrich Drepper. Copyright © 2002 . 
                                      
       ISO/IEC 14882:1998 Programming languages - C++
-    . Copyright © 1998 ISO. 
                                      
+    . Copyright © 1998 ISO. 
                                      
       ISO/IEC 9899:1999 Programming languages - C
-    . Copyright © 1999 ISO. 
                                      
+    . Copyright © 1999 ISO. 
                                      
       The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004)
     . Copyright © 1999 
       The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. 
       
       
-    . 
                                      
+    . 
                                      
       The C++ Programming Language, Special Edition
     . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. 
 	Addison Wesley
-      . 
                                      
+      . 
                                      
       Standard C++ IOStreams and Locales
     . 
       Advanced Programmer's Guide and Reference
diff --git a/libstdc++-v3/doc/html/manual/fstreams.html b/libstdc++-v3/doc/html/manual/fstreams.html
index bd8e8260988..6b0a06bca32 100644
--- a/libstdc++-v3/doc/html/manual/fstreams.html
+++ b/libstdc++-v3/doc/html/manual/fstreams.html
@@ -1,9 +1,9 @@
 
 
-Chapter 27. File Based Streams
                                      Chapter 27. File Based Streams
                                      Prev Part XI. 
+Chapter 27. File Based Streams
                                      Chapter 27. File Based Streams
                                      Prev Part XI. 
   Input and Output
   
- Next
                                      Chapter 27. File Based Streams
                                      Table of Contents
                                      Copying a File
                                      Binary Input and Output
                                      Copying a File
                                      
+
                                      		 Next
                                      Chapter 27. File Based Streams
                                      Table of Contents
                                      Copying a File
                                      Binary Input and Output
                                      Copying a File
                                      
   
                                      So you want to copy a file quickly and easily, and most important,
       completely portably.  And since this is C++, you have an open
       ifstream (call it IN) and an open ofstream (call it OUT):
diff --git a/libstdc++-v3/doc/html/manual/functors.html b/libstdc++-v3/doc/html/manual/functors.html
index eb469ed0b29..eca77856530 100644
--- a/libstdc++-v3/doc/html/manual/functors.html
+++ b/libstdc++-v3/doc/html/manual/functors.html
@@ -1,9 +1,9 @@
 
 
-Chapter 9. Functors
                                      Chapter 9. Functors
                                      Prev Part IV. 
+Chapter 9. Functors
                                      Chapter 9. Functors
                                      Prev Part IV. 
   Utilities
   
- Next
                                      Chapter 9. Functors
                                      If you don't know what functors are, you're not alone.  Many people
+
                                      		 Next
                                      Chapter 9. Functors
                                      If you don't know what functors are, you're not alone.  Many people
       get slightly the wrong idea.  In the interest of not reinventing
       the wheel, we will refer you to the introduction to the functor
       concept written by SGI as part of their STL, in
diff --git a/libstdc++-v3/doc/html/manual/fundamental_types.html b/libstdc++-v3/doc/html/manual/fundamental_types.html
index df1570c9824..0196e5a8dec 100644
--- a/libstdc++-v3/doc/html/manual/fundamental_types.html
+++ b/libstdc++-v3/doc/html/manual/fundamental_types.html
@@ -1,37 +1,37 @@
 
 
-Chapter 4. Types
                                      Chapter 4. Types
                                      Prev Part II. 
+Chapter 4. Types
                                      Chapter 4. Types
                                      Prev Part II. 
   Support
   
- Next
                                      Chapter 4. Types
                                      Table of Contents
                                      Fundamental Types
                                      Numeric Properties
                                      NULL
                                      Fundamental Types
                                      
+
                                      		 Next
                                      Chapter 4. Types
                                      Table of Contents
                                      Fundamental Types
                                      Numeric Properties
                                      NULL
                                      Fundamental Types
                                      
       C++ has the following builtin types:
-    
                                      • 
+    
                                        • 
 	char
-      
                                        • 
+      
                                        • 
 	signed char
-      
                                        • 
+      
                                        • 
 	unsigned char
-      
                                        • 
+      
                                        • 
 	signed short
-      
                                        • 
+      
                                        • 
 	signed int
-      
                                        • 
+      
                                        • 
 	signed long
-      
                                        • 
+      
                                        • 
 	unsigned short
-      
                                        • 
+      
                                        • 
 	unsigned int
-      
                                        • 
+      
                                        • 
 	unsigned long
-      
                                        • 
+      
                                        • 
 	bool
-      
                                        • 
+      
                                        • 
 	wchar_t
-      
                                        • 
+      
                                        • 
 	float
-      
                                        • 
+      
                                        • 
 	double
-      
                                        • 
+      
                                        • 
 	long double
       
                                        
       These fundamental types are always available, without having to
diff --git a/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html b/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html
index dc9bdd1cadf..74e54b47d44 100644
--- a/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html
+++ b/libstdc++-v3/doc/html/manual/generalized_numeric_operations.html
@@ -1,15 +1,15 @@
 
 
-Chapter 22. Generalized Operations
                                        Chapter 22. Generalized Operations
                                        Prev Part X. 
+Chapter 22. Generalized Operations
                                        Chapter 22. Generalized Operations
                                        Prev Part X. 
   Numerics
   
- Next
                                        Chapter 22. Generalized Operations
                                        
+
                                        		 Next
                                        Chapter 22. Generalized Operations
                                        
   
                                        There are four generalized functions in the <numeric> header
       that follow the same conventions as those in <algorithm>.  Each
       of them is overloaded:  one signature for common default operations,
       and a second for fully general operations.  Their names are
       self-explanatory to anyone who works with numerics on a regular basis:
-   
                                        • accumulate
                                        • inner_product
                                        • partial_sum
                                        • adjacent_difference
                                        Here is a simple example of the two forms of accumulate.
+   
                                        • accumulate
                                        • inner_product
                                        • partial_sum
                                        • adjacent_difference
                                        Here is a simple example of the two forms of accumulate.
    
                                            int   ar[50];
    int   someval = somefunction();
diff --git a/libstdc++-v3/doc/html/manual/internals.html b/libstdc++-v3/doc/html/manual/internals.html
index aca09ecaf51..cc6df8ba72c 100644
--- a/libstdc++-v3/doc/html/manual/internals.html
+++ b/libstdc++-v3/doc/html/manual/internals.html
@@ -1,9 +1,9 @@
 
 
-Porting to New Hardware or Operating Systems
                                        Porting to New Hardware or Operating Systems
                                        Prev Appendix B. 
+Porting to New Hardware or Operating Systems
                                        Porting to New Hardware or Operating Systems
                                        Prev Appendix B. 
   Porting and Maintenance
   
- Next
                                        Porting to New Hardware or Operating Systems
                                        
+
                                        		 Next
                                        Porting to New Hardware or Operating Systems
                                        
 
                                        This document explains how to port libstdc++ (the GNU C++ library) to
 a new target.
 
                                        In order to make the GNU C++ library (libstdc++) work with a new
@@ -20,7 +20,7 @@ works.  It is difficult to test the C++ compiler without a working
 library, but you should at least try some minimal test cases.
    
                                        (Note that what we think of as a "target," the library refers to as
 a "host."  The comment at the top of configure.ac explains why.)
-   
                                        Operating System
                                        If you are porting to a new operating system (as opposed to a new chip
+   
                                        Operating System
                                        If you are porting to a new operating system (as opposed to a new chip
 using an existing operating system), you will need to create a new
 directory in the config/os hierarchy.  For example, the IRIX
 configuration files are all in config/os/irix.  There is no set
@@ -99,7 +99,7 @@ this:
 #endif
 
                                        We recommend copying an existing os_defines.h to use as a
 starting point.
-   
                                        CPU
                                        If you are porting to a new chip (as opposed to a new operating system
+   
                                        CPU
                                        If you are porting to a new chip (as opposed to a new operating system
 running on an existing chip), you will need to create a new directory in the
 config/cpu hierarchy.  Much like the Operating system setup,
 there are no strict rules on how to organize the CPU configuration
@@ -117,7 +117,7 @@ example, alpha, alphaev5, an
    
                                        The cpu_include_dir sets default locations for the files controlling
 Thread safety and Numeric limits, if the defaults are not
 appropriate for your chip.
-   
                                        Character Types
                                        The library requires that you provide three header files to implement
+   
                                        Character Types
                                        The library requires that you provide three header files to implement
 character classification, analogous to that provided by the C libraries
 <ctype.h> header.  You can model these on the files provided in
 config/os/generic.  However, these files will almost
@@ -279,7 +279,7 @@ from __low up until __high i
          ++__low;
        return __low;
      }
-
                                      Thread Safety
                                      The C++ library string functionality requires a couple of atomic
+
                                      Thread Safety
                                      The C++ library string functionality requires a couple of atomic
 operations to provide thread-safety.  If you don't take any special
 action, the library will use stub versions of these functions that are
 not thread-safe.  They will work fine, unless your applications are
@@ -334,7 +334,7 @@ must be equivalent to those provided here, but using atomic operations:
      {
        *__mem += __val;
      }
-
                                      Numeric Limits
                                      The C++ library requires information about the fundamental data types,
+
                                      Numeric Limits
                                      The C++ library requires information about the fundamental data types,
 such as the minimum and maximum representable values of each type. 
 You can define each of these values individually, but it is usually
 easiest just to indicate how many bits are used in each of the data
@@ -346,7 +346,7 @@ same values, you can provide a CPU-specific file instead so that you
 do not have to provide the same definitions for each operating system. 
 To take that approach, create a new file called cpu_limits.h in
 your CPU configuration directory (see CPU).
-   
                                      Libtool
                                      The C++ library is compiled, archived and linked with libtool. 
+   
                                      Libtool
                                      The C++ library is compiled, archived and linked with libtool. 
 Explaining the full workings of libtool is beyond the scope of this
 document, but there are a few, particular bits that are necessary for
 porting.
diff --git a/libstdc++-v3/doc/html/manual/intro.html b/libstdc++-v3/doc/html/manual/intro.html
index 350d617ccc2..a5858916238 100644
--- a/libstdc++-v3/doc/html/manual/intro.html
+++ b/libstdc++-v3/doc/html/manual/intro.html
@@ -1,9 +1,9 @@
 
 
-Part I.  Introduction
                                      Part I. 
+Part I.  Introduction
                                      Part I. 
   Introduction
   
-
                                      Prev The GNU C++ Library Next
                                      Part I. 
+
                                      Prev The GNU C++ Library Next
                                      Part I. 
   Introduction
-  
-
                                      Table of Contents
                                      1. Status
                                      Implementation Status
                                      C++ 1998/2003
                                      C++ TR1
                                      C++ 200x
                                      C++ TR 24733
                                      License
                                      The Code: GPL
                                      The Documentation: GPL, FDL
                                      Bugs
                                      Implementation Bugs
                                      Standard Bugs
                                      2. Setup
                                      Prerequisites
                                      Configure
                                      Make
                                      3. Using
                                      Linking Library Binary Files
                                      Headers
                                      Header Files
                                      Mixing Headers
                                      The C Headers and namespace std
                                      Precompiled Headers
                                      Namespaces
                                      Available Namespaces
                                      namespace std
                                      Using Namespace Composition
                                      Macros
                                      Concurrency
                                      Prerequisites
                                      Thread Safety
                                      Atomics
                                      IO
                                      Containers
                                      Exceptions
                                      Exception Safety
                                      Exception Neutrality
                                      Doing without
                                      Compatibility
                                      Debugging Support
                                      Using g++
                                      Debug Versions of Library Binary Files
                                      Memory Leak Hunting
                                      Using gdb
                                      Tracking uncaught exceptions
                                      Debug Mode
                                      Compile Time Checking
                                      Profile-based Performance Analysis
                                      Prev Up Next
                                      The GNU C++ Library Home Chapter 1. Status
                                      
+  
+
                                    Table of Contents
                                    1. Status
                                    Implementation Status
                                    C++ 1998/2003
                                    C++ 200x
                                    C++ TR1
                                    C++ TR 24733
                                    License
                                    The Code: GPL
                                    The Documentation: GPL, FDL
                                    Bugs
                                    Implementation Bugs
                                    Standard Bugs
                                    2. Setup
                                    Prerequisites
                                    Configure
                                    Make
                                    3. Using
                                    Linking Library Binary Files
                                    Headers
                                    Header Files
                                    Mixing Headers
                                    The C Headers and namespace std
                                    Precompiled Headers
                                    Namespaces
                                    Available Namespaces
                                    namespace std
                                    Using Namespace Composition
                                    Macros
                                    Concurrency
                                    Prerequisites
                                    Thread Safety
                                    Atomics
                                    IO
                                    Containers
                                    Exceptions
                                    Exception Safety
                                    Exception Neutrality
                                    Doing without
                                    Compatibility
                                    Debugging Support
                                    Using g++
                                    Debug Versions of Library Binary Files
                                    Memory Leak Hunting
                                    Using gdb
                                    Tracking uncaught exceptions
                                    Debug Mode
                                    Compile Time Checking
                                    Profile-based Performance Analysis
                                  Prev Up Next
                                  The GNU C++ Library Home Chapter 1. Status
                                  
diff --git a/libstdc++-v3/doc/html/manual/io.html b/libstdc++-v3/doc/html/manual/io.html
index 1ede95bdcda..8c2c572db3c 100644
--- a/libstdc++-v3/doc/html/manual/io.html
+++ b/libstdc++-v3/doc/html/manual/io.html
@@ -1,9 +1,9 @@
 
 
-Part XI.  Input and Output
                                  Part XI. 
+Part XI.  Input and Output
                                  Part XI. 
   Input and Output
   
-
                                  Prev The GNU C++ Library Next
                                  Part XI. 
+
                                  Prev The GNU C++ Library Next
                                  Part XI. 
   Input and Output
-  
+  
 
                                  Table of Contents
                                  24. Iostream Objects
                                  25. Stream Buffers
                                  Derived streambuf Classes
                                  Buffering
                                  26. Memory Based Streams
                                  Compatibility With strstream
                                  27. File Based Streams
                                  Copying a File
                                  Binary Input and Output
                                  28. Interacting with C
                                  Using FILE* and file descriptors
                                  Performance
                                  Prev Up Next
                                  C99 Home Chapter 24. Iostream Objects
                                  
diff --git a/libstdc++-v3/doc/html/manual/io_and_c.html b/libstdc++-v3/doc/html/manual/io_and_c.html
index e5fe3c77da2..33b5796ca27 100644
--- a/libstdc++-v3/doc/html/manual/io_and_c.html
+++ b/libstdc++-v3/doc/html/manual/io_and_c.html
@@ -1,9 +1,9 @@
 
 
-Chapter 28. Interacting with C
                                  Chapter 28. Interacting with C
                                  Prev Part XI. 
+Chapter 28. Interacting with C
                                  Chapter 28. Interacting with C
                                  Prev Part XI. 
   Input and Output
   
- Next
                                  Chapter 28. Interacting with C
                                  Table of Contents
                                  Using FILE* and file descriptors
                                  Performance
                                  Using FILE* and file descriptors
                                  
+
                                  		 Next
                                  Chapter 28. Interacting with C
                                  Table of Contents
                                  Using FILE* and file descriptors
                                  Performance
                                  Using FILE* and file descriptors
                                  
       See the extensions for using
       FILE and file descriptors with
       ofstream and
diff --git a/libstdc++-v3/doc/html/manual/iostream_objects.html b/libstdc++-v3/doc/html/manual/iostream_objects.html
index 704aa7de1b0..1133edec3ab 100644
--- a/libstdc++-v3/doc/html/manual/iostream_objects.html
+++ b/libstdc++-v3/doc/html/manual/iostream_objects.html
@@ -1,9 +1,9 @@
 
 
-Chapter 24. Iostream Objects
                                  Chapter 24. Iostream Objects
                                  Prev Part XI. 
+Chapter 24. Iostream Objects
                                  Chapter 24. Iostream Objects
                                  Prev Part XI. 
   Input and Output
   
- Next
                                  Chapter 24. Iostream Objects
                                  To minimize the time you have to wait on the compiler, it's good to
+
                                  		 Next
                                  Chapter 24. Iostream Objects
                                  To minimize the time you have to wait on the compiler, it's good to
       only include the headers you really need.  Many people simply include
       <iostream> when they don't need to -- and that can penalize
       your runtime as well.  Here are some tips on which header to use
diff --git a/libstdc++-v3/doc/html/manual/iterators.html b/libstdc++-v3/doc/html/manual/iterators.html
index a002097bfcd..5122b6bef04 100644
--- a/libstdc++-v3/doc/html/manual/iterators.html
+++ b/libstdc++-v3/doc/html/manual/iterators.html
@@ -1,9 +1,9 @@
 
 
-Part VIII.  Iterators
                                  Part VIII. 
+Part VIII.  Iterators
                                  Part VIII. 
   Iterators
   
-
                                  Prev The GNU C++ Library Next
                                  Part VIII. 
+
                                  Prev The GNU C++ Library Next
                                  Part VIII. 
   Iterators
-  
+  
 
                                  Table of Contents
                                  19. Predefined
                                  Iterators vs. Pointers
                                  One Past the End
                                  Prev Up Next
                                  bitset Home Chapter 19. Predefined
                                  
diff --git a/libstdc++-v3/doc/html/manual/license.html b/libstdc++-v3/doc/html/manual/license.html
index 086902de214..f660ff378a0 100644
--- a/libstdc++-v3/doc/html/manual/license.html
+++ b/libstdc++-v3/doc/html/manual/license.html
@@ -1,15 +1,15 @@
 
 
-License
                                  License
                                  Prev Chapter 1. Status Next
                                  License
                                  
+License
                                  License
                                  Prev Chapter 1. Status Next
                                  License
                                  
     There are two licenses affecting GNU libstdc++: one for the code,
     and one for the documentation.  
     
                                  
       There is a license section in the FAQ regarding common questions. If you have more
       questions, ask the FSF or the gcc mailing list.
-    
                                  The Code: GPL
                                  
+    
                                  The Code: GPL
                                  
       The source code is distributed under the GNU General Public License version 3,
       with the addition under section 7 of an exception described in
-      the “GCC Runtime Library Exception, version 3.1”
+      the “GCC Runtime Library Exception, version 3.1”
       as follows (or see the file COPYING.RUNTIME):
     

                                  
 GCC RUNTIME LIBRARY EXCEPTION
                                  
@@ -87,7 +87,7 @@ requirements of the license of GCC.
                                  
     
                                  
       Hopefully that text is self-explanatory.  If it isn't, you need to speak
       to your lawyer, or the Free Software Foundation.
-    
                                  The Documentation: GPL, FDL
                                  
+    
                                  The Documentation: GPL, FDL
                                  
       The documentation shipped with the library and made available over
       the web, excluding the pages generated from source comments, are
       copyrighted by the Free Software Foundation, and placed under the
diff --git a/libstdc++-v3/doc/html/manual/locales.html b/libstdc++-v3/doc/html/manual/locales.html
index 296e8aecbba..4bf83c79ecc 100644
--- a/libstdc++-v3/doc/html/manual/locales.html
+++ b/libstdc++-v3/doc/html/manual/locales.html
@@ -1,13 +1,13 @@
 
 
-Chapter 14. Locales
                                  Chapter 14. Locales
                                  Prev Part VI. 
+Chapter 14. Locales
                                  Chapter 14. Locales
                                  Prev Part VI. 
   Localization
   
- Next
                                  Chapter 14. Locales
                                  Table of Contents
                                  locale
                                  Requirements
                                  Design
                                  Implementation
                                  Future
                                  locale
                                  
+
                                  		 Next
                                  Chapter 14. Locales
                                  Table of Contents
                                  locale
                                  Requirements
                                  Design
                                  Implementation
                                  Future
                                  locale
                                  
 Describes the basic locale object, including nested
 classes id, facet, and the reference-counted implementation object,
 class _Impl.
-
                                  Requirements
                                  
+
                                  Requirements
                                  
 Class locale is non-templatized and has two distinct types nested
 inside of it:
 
                                  
@@ -21,11 +21,11 @@ called numpunct is the data objects that can be used to query for the
 thousands separator is in the German locale.
 
                                  
 Literally, a facet is strictly defined:
-
                                  • 
+
                                    • 
       Containing the following public data member:
     
                                      
       static locale::id id;
-    
                                    • 
+    
                                    • 
       Derived from another facet:
     
                                      
       class gnu_codecvt: public std::ctype<user-defined-type>
@@ -43,14 +43,14 @@ class id
 
 
                                  
 Provides an index for looking up specific facets.
-
                                  Design
                                  
+
                                  Design
                                  
 The major design challenge is fitting an object-orientated and
 non-global locale design on top of POSIX and other relevant standards,
 which include the Single Unix (nee X/Open.)
 
                                  
 Because C and earlier versions of POSIX fall down so completely,
 portability is an issue.
-
                                  Implementation
                                  Interacting with "C" locales
                                  •  
+
                                  Implementation
                                  Interacting with "C" locales
                                  •  
        `locale -a` displays available locales. 
      
                                     af_ZA
@@ -351,7 +351,7 @@ zh_HK.utf8
 zh_TW
 zh_TW.euctw
 zh_TW.utf8
-
                                  •  
+
                                •  
        `locale` displays environmental variables that
        impact how locale("") will be deduced.
      
                                  @@ -380,43 +380,43 @@ global locale" (emphasis Paolo), that is:
   particular on the working of locale(""), which constructs the locale
   object from the environment of the running program, that is, in
   practice, the set of LC_ALL, LANG, etc. variable of the shell.
-
                                Future
                                • 
+
                                Future
                                • 
        Locale initialization: at what point does _S_classic, _S_global
        get initialized? Can named locales assume this initialization
        has already taken place? 
-     
                                •  
+     
                                •  
        Document how named locales error check when filling data
        members. I.e., a fr_FR locale that doesn't have
        numpunct::truename(): does it use "true"? Or is it a blank
        string? What's the convention? 
-   
                                •  
+   
                                •  
        Explain how locale aliasing happens. When does "de_DE" use "de"
        information? What is the rule for locales composed of just an
        ISO language code (say, "de") and locales with both an ISO
        language code and ISO country code (say, "de_DE"). 
-     
                                •  
+     
                                •  
        What should non-required facet instantiations do?  If the
        generic implementation is provided, then how to end-users
        provide specializations? 
-   
                                Bibliography
                                
+   
                            Bibliography
                            
       The GNU C Library
-    . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization. 
                            
+    . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling and 7 Locales and Internationalization. 
                            
       Correspondence
-    . Ulrich Drepper. Copyright © 2002 . 
                            
+    . Ulrich Drepper. Copyright © 2002 . 
                            
       ISO/IEC 14882:1998 Programming languages - C++
-    . Copyright © 1998 ISO. 
                            
+    . Copyright © 1998 ISO. 
                            
       ISO/IEC 9899:1999 Programming languages - C
-    . Copyright © 1999 ISO. 
                            
+    . Copyright © 1999 ISO. 
                            
       The Open Group Base Specifications, Issue 6 (IEEE Std. 1003.1-2004)
     . Copyright © 1999 
       The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. 
       
       
-    . 
                            
+    . 
                            
       The C++ Programming Language, Special Edition
     . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. 
 	Addison Wesley
-      . 
                            
+      . 
                            
       Standard C++ IOStreams and Locales
     . 
       Advanced Programmer's Guide and Reference
diff --git a/libstdc++-v3/doc/html/manual/localization.html b/libstdc++-v3/doc/html/manual/localization.html
index 152956fa176..05133c37eda 100644
--- a/libstdc++-v3/doc/html/manual/localization.html
+++ b/libstdc++-v3/doc/html/manual/localization.html
@@ -1,9 +1,9 @@
 
 
-Part VI.  Localization
                            Part VI. 
+Part VI.  Localization
                            Part VI. 
   Localization
   
-
                            Prev The GNU C++ Library Next
                            Part VI. 
+
                            Prev The GNU C++ Library Next
                            Part VI. 
   Localization
-  
+  
 
                            Table of Contents
                            14. Locales
                            locale
                            Requirements
                            Design
                            Implementation
                            Future
                            15. Facets aka Categories
                            ctype
                            Implementation
                            Future
                            codecvt
                            Requirements
                            Design
                            Implementation
                            Use
                            Future
                            messages
                            Requirements
                            Design
                            Implementation
                            Use
                            Future
                            Prev Up Next
                            CString (MFC) Home Chapter 14. Locales
                            
diff --git a/libstdc++-v3/doc/html/manual/make.html b/libstdc++-v3/doc/html/manual/make.html
index 2563d277938..d3066e93934 100644
--- a/libstdc++-v3/doc/html/manual/make.html
+++ b/libstdc++-v3/doc/html/manual/make.html
@@ -1,6 +1,6 @@
 
 
-Make
                            Make
                            Prev Chapter 2. Setup Next
                            Make
                            If you have never done this before, you should read the basic
+Make
                            Make
                            Prev Chapter 2. Setup Next
                            Make
                            If you have never done this before, you should read the basic
       GCC Installation
       Instructions first.  Read all of them.
       Twice.
diff --git a/libstdc++-v3/doc/html/manual/memory.html b/libstdc++-v3/doc/html/manual/memory.html
index b49003b7a82..89e1e9021de 100644
--- a/libstdc++-v3/doc/html/manual/memory.html
+++ b/libstdc++-v3/doc/html/manual/memory.html
@@ -1,25 +1,25 @@
 
 
-Chapter 11. Memory
                            Chapter 11. Memory
                            Prev Part IV. 
+Chapter 11. Memory
                            Chapter 11. Memory
                            Prev Part IV. 
   Utilities
   
- Next
                            Chapter 11. Memory
                            Table of Contents
                            Allocators
                            Requirements
                            Design Issues
                            Implementation
                            Using a Specific Allocator
                            Custom Allocators
                            Extension Allocators
                            auto_ptr
                            Limitations
                            Use in Containers
                            shared_ptr
                            Requirements
                            Design Issues
                            Implementation
                            Use
                            Acknowledgments
                            
+
                            		 Next
                            Chapter 11. Memory
                            Table of Contents
                            Allocators
                            Requirements
                            Design Issues
                            Implementation
                            Using a Specific Allocator
                            Custom Allocators
                            Extension Allocators
                            auto_ptr
                            Limitations
                            Use in Containers
                            shared_ptr
                            Requirements
                            Design Issues
                            Implementation
                            Use
                            Acknowledgments
                            
     Memory contains three general areas. First, function and operator
     calls via new and delete
     operator or member function calls.  Second, allocation via
     allocator. And finally, smart pointer and
     intelligent pointer abstractions.
-  
                            Allocators
                            
+  
                            Allocators
                            
  Memory management for Standard Library entities is encapsulated in a
  class template called allocator. The
  allocator abstraction is used throughout the
  library in string, container classes,
  algorithms, and parts of iostreams. This class, and base classes of
- it, are the superset of available free store (“heap”)
+ it, are the superset of available free store (“heap”)
  management classes.
-
                            Requirements
                            
+
                            Requirements
                            
     The C++ standard only gives a few directives in this area:
-  
                            • 
+  
                              • 
        When you add elements to a container, and the container must
        allocate more memory to hold them, the container makes the
        request via its Allocator template
@@ -27,10 +27,10 @@
        allocator_type.  This includes adding chars
        to the string class, which acts as a regular STL container in
        this respect.
-      
                              • 
+      
                              • 
        The default Allocator argument of every
        container-of-T is allocator<T>.
-       
                              • 
+       
                              • 
        The interface of the allocator<T> class is
          extremely simple.  It has about 20 public declarations (nested
          typedefs, member functions, etc), but the two which concern us most
@@ -44,7 +44,7 @@
 	 T's to allocate space for, not their
 	 total size.
 	 (This is a simplification; the real signatures use nested typedefs.)  
-       
                              • 
+       
                              • 
 	 The storage is obtained by calling ::operator
 	 new, but it is unspecified when or how
 	 often this function is called.  The use of the 
@@ -54,7 +54,7 @@
        
                               
      Complete details cam be found in the C++ standard, look in
      [20.4 Memory].
-   
                            Design Issues
                            
+   
                            Design Issues
                            
     The easiest way of fulfilling the requirements is to call
     operator new each time a container needs
     memory, and to call operator delete each time
@@ -93,7 +93,7 @@
     or loading and unloading shared objects in memory. As such, using
     caching allocators on systems that do not support
     abi::__cxa_atexit is not recommended.
-  
                            Implementation
                            Interface Design
                            
+  
                            Implementation
                            Interface Design
                            
      The only allocator interface that
      is support is the standard C++ interface. As such, all STL
      containers have been adjusted, and all external allocators have
@@ -106,7 +106,7 @@
    
                             
      The base class that allocator is derived from
      may not be user-configurable.
-
                            Selecting Default Allocation Policy
                             
+
                            Selecting Default Allocation Policy
                             
      It's difficult to pick an allocation strategy that will provide
    maximum utility, without excessively penalizing some behavior. In
    fact, it's difficult just deciding which typical actions to measure
@@ -114,7 +114,7 @@
    
                             
      Three synthetic benchmarks have been created that provide data
      that is used to compare different C++ allocators. These tests are:
-   
                            1. 
+   
                              1. 
        Insertion. 
        
                                
        Over multiple iterations, various STL container
@@ -123,7 +123,7 @@
      Test source for sequence
      and associative
      containers.
-       
                              2. 
+       
                              3. 
        Insertion and erasure in a multi-threaded environment.
        
                                
        This test shows the ability of the allocator to reclaim memory
@@ -131,7 +131,7 @@
      for memory resources. 
      Test source 
     here.
-       
                              4. 
+       
                              5. 
 	 A threaded producer/consumer model.
        
                                
        Test source for
@@ -143,7 +143,7 @@
      The current default choice for
      allocator is
      __gnu_cxx::new_allocator.
-   
                              Disabling Memory Caching
                               
+   
                              Disabling Memory Caching
                               
       In use, allocator may allocate and
       deallocate using implementation-specified strategies and
       heuristics. Because of this, every call to an allocator object's
@@ -179,7 +179,7 @@
      environment, it likely means that you linked against objects
      built against the older library (objects which might still using the
      cached allocations...).
-  
                            Using a Specific Allocator
                            
+  
                            Using a Specific Allocator
                            
      You can specify different memory management schemes on a
      per-container basis, by overriding the default
      Allocator template parameter.  For example, an easy
@@ -190,7 +190,7 @@
       Likewise, a debugging form of whichever allocator is currently in use:
     
                                 std::deque <int, __gnu_cxx::debug_allocator<std::allocator<int> > >  debug_deque;
-      
                            Custom Allocators
                             
+      
                            Custom Allocators
                             
     Writing a portable C++ allocator would dictate that the interface
     would look much like the one specified for
     allocator. Additional member functions, but
@@ -199,7 +199,7 @@
      Probably the best place to start would be to copy one of the
    extension allocators: say a simple one like 
    new_allocator.
-   
                            Extension Allocators
                             
+   
                            Extension Allocators
                             
     Several other allocators are provided as part of this
     implementation.  The location of the extension allocators and their
     names have changed, but in all cases, functionality is
@@ -209,12 +209,12 @@
     chart to track the changes.
   
                            
     More details on each of these extension allocators follows.
-  
                            1. 
+  
                              1. 
        new_allocator
        
                                
 	 Simply wraps ::operator new
 	 and ::operator delete.
-       
                              2. 
+       
                              3. 
        malloc_allocator
        
                                
 	 Simply wraps malloc and
@@ -222,7 +222,7 @@
 	 out-of-memory handler (for
 	 new/delete this is
 	 taken care of elsewhere).
-       
                              4. 
+       
                              5. 
        array_allocator
        
                                
 	 Allows allocations of known and fixed sizes using existing
@@ -235,7 +235,7 @@
 	 allows the use of STL abstractions without runtime
 	 complications or overhead, even in situations such as program
 	 startup. For usage examples, please consult the testsuite.
-       
                              6. 
+       
                              7. 
        debug_allocator
        
                                 
 	 A wrapper around an arbitrary allocator A.  It passes on
@@ -244,13 +244,13 @@
 	 to deallocate(), the stored size is
 	 checked, and assert() is used to
 	 guarantee they match.
-       
                              8. 
+       
                              9. 
 	throw_allocator
 	
                                 
 	  Includes memory tracking and marking abilities as well as hooks for
 	  throwing exceptions at configurable intervals (including random,
 	  all, none). 
-	
                              10. 
+	
                              11. 
        __pool_alloc
        
                                 
 	 A high-performance, single pool allocator.  The reusable
@@ -296,23 +296,23 @@
      (Note that the GCC thread abstraction layer allows us to provide
      safe zero-overhead stubs for the threading routines, if threads
      were disabled at configuration time.)
-   
                              12. 
+   
                              13. 
        __mt_alloc
        
                                
 	 A high-performance fixed-size allocator with
 	 exponentially-increasing allocations. It has its own
 	 documentation, found here.
-       
                              14. 
+       
                              15. 
        bitmap_allocator
        
                                
 	 A high-performance allocator that uses a bit-map to keep track
 	 of the used and unused memory locations. It has its own
 	 documentation, found here.
-       
                            Bibliography
                            
+       
                          Bibliography
                          
     ISO/IEC 14882:1998 Programming languages - C++  
     . 
       isoc++_1998
-    20.4 Memory. 
                          The Standard Librarian: What Are Allocators Good
+    20.4 Memory. 
                          The Standard Librarian: What Are Allocators Good
     . 
       austernm
     Matt Austern. 
@@ -320,28 +320,28 @@
       . 
       
       
-    . 
                          The Hoard Memory Allocator. 
+    . 
                          The Hoard Memory Allocator. 
       emeryb
     Emery Berger. 
       
       
-    . 
                          Reconsidering Custom Memory Allocation. 
+    . 
                          Reconsidering Custom Memory Allocation. 
       bergerzorn
     Emery Berger. Ben Zorn. Kathryn McKinley. Copyright © 2002 OOPSLA. 
       
       
-    . 
                          Allocator Types. 
+    . 
                          Allocator Types. 
       kreftlanger
     Klaus Kreft. Angelika Langer. 
 	C/C++ Users Journal	
       . 
       
       
-    . 
                          The C++ Programming Language. 
+    . 
                          The C++ Programming Language. 
       tcpl
     Bjarne Stroustrup. Copyright © 2000 . 19.4 Allocators. 
 	Addison Wesley
-      . 
                          Yalloc: A Recycling C++ Allocator. 
+      . 
                          Yalloc: A Recycling C++ Allocator. 
       yenf
     Felix Yen. Copyright ©  . 
       
diff --git a/libstdc++-v3/doc/html/manual/messages.html b/libstdc++-v3/doc/html/manual/messages.html
index e21adac3025..6646aecbd83 100644
--- a/libstdc++-v3/doc/html/manual/messages.html
+++ b/libstdc++-v3/doc/html/manual/messages.html
@@ -1,10 +1,10 @@
 
 
-messages
                          messages
                          Prev Chapter 15. Facets aka Categories Next
                          messages
                          
+messages
                          messages
                          Prev Chapter 15. Facets aka Categories Next
                          messages
                          
 The std::messages facet implements message retrieval functionality
 equivalent to Java's java.text.MessageFormat .using either GNU gettext
 or IEEE 1003.1-200 functions.
-
                          Requirements
                          
+
                          Requirements
                          
 The std::messages facet is probably the most vaguely defined facet in
 the standard library. It's assumed that this facility was built into
 the standard library in order to convert string literals from one
@@ -53,7 +53,7 @@ be found, returns dfault.
 -6- Effects: Releases unspecified resources associated with cat. 
 -7- Notes: The limit on such resources, if any, is implementation-defined. 
 
-
                          Design
                          
+
                          Design
                          
 A couple of notes on the standard. 
 
                          
 First, why is messages_base::catalog specified as a typedef
@@ -85,7 +85,7 @@ It is implicitly assumed that the locale for the default message
 string in 'get' is in the "C" locale. Thus, all source code is assumed
 to be written in English, so translations are always from "en_US" to
 other, explicitly named locales.
-
                          Implementation
                          Models
                          
+
                          Implementation
                          Models
                          
     This is a relatively simple class, on the face of it. The standard
     specifies very little in concrete terms, so generic
     implementations that are conforming yet do very little are the
@@ -96,11 +96,11 @@ other, explicitly named locales.
   
                          
     Three different mechanisms have been provided, selectable via
     configure flags:
-  
                          • 
+  
                            • 
        generic
      
                              
        This model does very little, and is what is used by default.   
-     
                            •  
+     
                            •  
        gnu
      
                              
        The gnu model is complete and fully tested. It's based on the
@@ -110,7 +110,7 @@ other, explicitly named locales.
        relatively straight-forward process and is lightly documented
        below, and fully documented in gettext's distributed
        documentation.
-     
                            •  
+     
                            •  
        ieee_1003.1-200x
      
                              
        This is a complete, though untested, implementation based on
@@ -126,7 +126,7 @@ A new, standards-conformant non-virtual member function signature was
 added for 'open' so that a directory could be specified with a given
 message catalog. This simplifies calling conventions for the gnu
 model.
-
                            The GNU Model
                            
+
                            The GNU Model
                            
     The messages facet, because it is retrieving and converting
     between characters sets, depends on the ctype and perhaps the
     codecvt facet in a given locale. In addition, underlying "C"
@@ -138,38 +138,38 @@ model.
     Making the message catalogs can be initially tricky, but become
     quite simple with practice. For complete info, see the gettext
     documentation. Here's an idea of what is required:
-  
                            • 
+  
                              • 
        Make a source file with the required string literals that need
        to be translated. See intl/string_literals.cc for
        an example.
-     
                              •  
+     
                              •  
        Make initial catalog (see "4 Making the PO Template File" from
        the gettext docs).
                                
     xgettext --c++ --debug string_literals.cc -o libstdc++.pot 
-   
                              • Make language and country-specific locale catalogs.
                                
+   
                              • Make language and country-specific locale catalogs.
                                
    cp libstdc++.pot fr_FR.po
    
                                
    cp libstdc++.pot de_DE.po
-   
                              • 
+   
                              • 
        Edit localized catalogs in emacs so that strings are
        translated.
      
                                
    emacs fr_FR.po
-   
                              • Make the binary mo files.
                                
+   
                              • Make the binary mo files.
                                
    msgfmt fr_FR.po -o fr_FR.mo
    
                                
    msgfmt de_DE.po -o de_DE.mo
-   
                              • Copy the binary files into the correct directory structure.
                                
+   
                              • Copy the binary files into the correct directory structure.
                                
    cp fr_FR.mo (dir)/fr_FR/LC_MESSAGES/libstdc++.mo
    
                                
    cp de_DE.mo (dir)/de_DE/LC_MESSAGES/libstdc++.mo
-   
                              • Use the new message catalogs.
                                
+   
                              • Use the new message catalogs.
                                
    locale loc_de("de_DE");
    
                                
    
    use_facet<messages<char> >(loc_de).open("libstdc++", locale(), dir);
    
-   
                            Use
                            
+   
                          Use
                          
    A simple example using the GNU model of message conversion.
  
                           #include <iostream>
@@ -191,9 +191,9 @@ void test01()
   cout << "thank you in german:" << s02 << '\n';
   mssg_de.close(cat_de);
 }
-
                          Future
                          • 
+
                          Future
                          • 
     Things that are sketchy, or remain unimplemented:
-  
                            • 
+  
                              • 
 	  _M_convert_from_char, _M_convert_to_char are in flux,
 	  depending on how the library ends up doing character set
 	  conversions. It might not be possible to do a real character
@@ -201,13 +201,13 @@ void test01()
 	  parameter for messages is not enough to instantiate the
 	  codecvt facet (1 supplied, need at least 2 but would prefer
 	  3).
-	
                              •  
+	
                              •  
 	  There are issues with gettext needing the global locale set
 	  to extract a message. This dependence on the global locale
 	  makes the current "gnu" model non MT-safe. Future versions
 	  of glibc, i.e. glibc 2.3.x will fix this, and the C++ library
 	  bits are already in place.
-	
                            •   
+	
                          •   
     Development versions of the GNU "C" library, glibc 2.3 will allow
     a more efficient, MT implementation of std::messages, and will
     allow the removal of the _M_name_messages data member. If this is
@@ -216,7 +216,7 @@ void test01()
     version of the "C" library is released, the marked parts of the
     messages implementation can be switched over to the new "C"
     library functionality.
-  
                          • 
+  
                          • 
     At some point in the near future, std::numpunct will probably use
     std::messages facilities to implement truename/falsename
     correctly. This is currently not done, but entries in
@@ -225,7 +225,7 @@ void test01()
     configure/make hassles to make the installed library search its
     own catalog. Currently the libstdc++.mo catalog is only searched
     for the testsuite cases involving messages members.
-  
                          •  The following member functions:
                            
+  
                          •  The following member functions:
                            
    
         catalog 
         open(const basic_string<char>& __s, const locale& __loc) const
@@ -241,38 +241,38 @@ void test01()
    model. As of this writing, it is unknown how to query to see
    if a specified message catalog exists using the gettext
    package.
-   
                          Bibliography
                          
+   
                        Bibliography
                        
       The GNU C Library
     . Roland McGrath. Ulrich Drepper. Copyright © 2007 FSF. Chapters 6 Character Set Handling, and 7 Locales and Internationalization
-    . 
                        
+    . 
                        
       Correspondence
-    . Ulrich Drepper. Copyright © 2002 . 
                        
+    . Ulrich Drepper. Copyright © 2002 . 
                        
       ISO/IEC 14882:1998 Programming languages - C++
-    . Copyright © 1998 ISO. 
                        
+    . Copyright © 1998 ISO. 
                        
       ISO/IEC 9899:1999 Programming languages - C
-    . Copyright © 1999 ISO. 
                        
+    . Copyright © 1999 ISO. 
                        
       System Interface Definitions, Issue 6 (IEEE Std. 1003.1-200x)
     . Copyright © 1999 
       The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. 
       
       
-    . 
                        
+    . 
                        
       The C++ Programming Language, Special Edition
     . Bjarne Stroustrup. Copyright © 2000 Addison Wesley, Inc.. Appendix D. 
 	Addison Wesley
-      . 
                        
+      . 
                        
       Standard C++ IOStreams and Locales
     . 
       Advanced Programmer's Guide and Reference
     . Angelika Langer. Klaus Kreft. Copyright © 2000 Addison Wesley Longman, Inc.. 
 	Addison Wesley Longman
-      . 
                        
+      . 
                        
       Java 2 Platform, Standard Edition, v 1.3.1 API Specification
     . java.util.Properties, java.text.MessageFormat,
 java.util.Locale, java.util.ResourceBundle. 
       
       
-    . 
                        
+    . 
                        
        GNU gettext tools, version 0.10.38, Native Language Support
 Library and Tools.
     . 
diff --git a/libstdc++-v3/doc/html/manual/numerics.html b/libstdc++-v3/doc/html/manual/numerics.html
index 457f548f437..2974fdd0997 100644
--- a/libstdc++-v3/doc/html/manual/numerics.html
+++ b/libstdc++-v3/doc/html/manual/numerics.html
@@ -1,9 +1,9 @@
 
 
-Part X.  Numerics
                        Part X. 
+Part X.  Numerics
                        Part X. 
   Numerics
   
-
                        Prev The GNU C++ Library Next
                        Part X. 
+
                        Prev The GNU C++ Library Next
                        Part X. 
   Numerics
-  
+  
 
                        Table of Contents
                        21. Complex
                        complex Processing
                        22. Generalized Operations
                        23. Interacting with C
                        Numerics vs. Arrays
                        C99
                        Prev Up Next
                        Chapter 20. Mutating Home Chapter 21. Complex
                        
diff --git a/libstdc++-v3/doc/html/manual/numerics_and_c.html b/libstdc++-v3/doc/html/manual/numerics_and_c.html
index 1179f0d5af7..0bd1b809371 100644
--- a/libstdc++-v3/doc/html/manual/numerics_and_c.html
+++ b/libstdc++-v3/doc/html/manual/numerics_and_c.html
@@ -1,9 +1,9 @@
 
 
-Chapter 23. Interacting with C
                        Chapter 23. Interacting with C
                        Prev Part X. 
+Chapter 23. Interacting with C
                        Chapter 23. Interacting with C
                        Prev Part X. 
   Numerics
   
- Next
                        Chapter 23. Interacting with C
                        Table of Contents
                        Numerics vs. Arrays
                        C99
                        Numerics vs. Arrays
                        One of the major reasons why FORTRAN can chew through numbers so well
+
                        		 Next
                        Chapter 23. Interacting with C
                        Table of Contents
                        Numerics vs. Arrays
                        C99
                        Numerics vs. Arrays
                        One of the major reasons why FORTRAN can chew through numbers so well
       is that it is defined to be free of pointer aliasing, an assumption
       that C89 is not allowed to make, and neither is C++98.  C99 adds a new
       keyword, restrict, to apply to individual pointers.  The
diff --git a/libstdc++-v3/doc/html/manual/pairs.html b/libstdc++-v3/doc/html/manual/pairs.html
index 99c9e7bc9b5..3b4981bbaa8 100644
--- a/libstdc++-v3/doc/html/manual/pairs.html
+++ b/libstdc++-v3/doc/html/manual/pairs.html
@@ -1,9 +1,9 @@
 
 
-Chapter 10. Pairs
                        Chapter 10. Pairs
                        Prev Part IV. 
+Chapter 10. Pairs
                        Chapter 10. Pairs
                        Prev Part IV. 
   Utilities
   
- Next
                        Chapter 10. Pairs
                        The pair<T1,T2> is a simple and handy way to
+
                        		 Next
                        Chapter 10. Pairs
                        The pair<T1,T2> is a simple and handy way to
       carry around a pair of objects.  One is of type T1, and another of
       type T2; they may be the same type, but you don't get anything
       extra if they are.  The two members can be accessed directly, as
diff --git a/libstdc++-v3/doc/html/manual/parallel_mode.html b/libstdc++-v3/doc/html/manual/parallel_mode.html
index 635ef1dd6a1..c17295d06be 100644
--- a/libstdc++-v3/doc/html/manual/parallel_mode.html
+++ b/libstdc++-v3/doc/html/manual/parallel_mode.html
@@ -1,9 +1,9 @@
 
 
-Chapter 31. Parallel Mode
                        Chapter 31. Parallel Mode
                        Prev Part XII. 
+Chapter 31. Parallel Mode
                        Chapter 31. Parallel Mode
                        Prev Part XII. 
   Extensions
   
- Next
                        Chapter 31. Parallel Mode
                        Table of Contents
                        Intro
                        Semantics
                        Using
                        Prerequisite Compiler Flags
                        Using Parallel Mode
                        Using Specific Parallel Components
                        Design
                        Interface Basics
                        Configuration and Tuning
                        Implementation Namespaces
                        Testing
                        Bibliography
                         The libstdc++ parallel mode is an experimental parallel
+
                        		 Next
                        Chapter 31. Parallel Mode
                        Table of Contents
                        Intro
                        Semantics
                        Using
                        Prerequisite Compiler Flags
                        Using Parallel Mode
                        Using Specific Parallel Components
                        Design
                        Interface Basics
                        Configuration and Tuning
                        Implementation Namespaces
                        Testing
                        Bibliography
                         The libstdc++ parallel mode is an experimental parallel
 implementation of many algorithms the C++ Standard Library.
 
                        
 Several of the standard algorithms, for instance
@@ -11,13 +11,13 @@ Several of the standard algorithms, for instance
 annotations. These parallel mode constructs and can be invoked by
 explicit source declaration or by compiling existing sources with a
 specific compiler flag.
-
                        Intro
                        The following library components in the include
-numeric are included in the parallel mode:
                        • std::accumulate
                        • std::adjacent_difference
                        • std::inner_product
                        • std::partial_sum
                        The following library components in the include
-algorithm are included in the parallel mode:
                        • std::adjacent_find
                        • std::count
                        • std::count_if
                        • std::equal
                        • std::find
                        • std::find_if
                        • std::find_first_of
                        • std::for_each
                        • std::generate
                        • std::generate_n
                        • std::lexicographical_compare
                        • std::mismatch
                        • std::search
                        • std::search_n
                        • std::transform
                        • std::replace
                        • std::replace_if
                        • std::max_element
                        • std::merge
                        • std::min_element
                        • std::nth_element
                        • std::partial_sort
                        • std::partition
                        • std::random_shuffle
                        • std::set_union
                        • std::set_intersection
                        • std::set_symmetric_difference
                        • std::set_difference
                        • std::sort
                        • std::stable_sort
                        • std::unique_copy
                        Bibliography
                        
+
                        Intro
                        The following library components in the include
+numeric are included in the parallel mode:
                        • std::accumulate
                        • std::adjacent_difference
                        • std::inner_product
                        • std::partial_sum
                        The following library components in the include
+algorithm are included in the parallel mode:
                        • std::adjacent_find
                        • std::count
                        • std::count_if
                        • std::equal
                        • std::find
                        • std::find_if
                        • std::find_first_of
                        • std::for_each
                        • std::generate
                        • std::generate_n
                        • std::lexicographical_compare
                        • std::mismatch
                        • std::search
                        • std::search_n
                        • std::transform
                        • std::replace
                        • std::replace_if
                        • std::max_element
                        • std::merge
                        • std::min_element
                        • std::nth_element
                        • std::partial_sort
                        • std::partition
                        • std::random_shuffle
                        • std::set_union
                        • std::set_intersection
                        • std::set_symmetric_difference
                        • std::set_difference
                        • std::sort
                        • std::stable_sort
                        • std::unique_copy
                        Bibliography
                        
       Parallelization of Bulk Operations for STL Dictionaries
     . Johannes Singler. Leonor Frias. Copyright © 2007 . 
 	Workshop on Highly Parallel Processing on a Chip (HPPC) 2007. (LNCS)
-      . 
                        
+      . 
                        
       The Multi-Core Standard Template Library
     . Johannes Singler. Peter Sanders. Felix Putze. Copyright © 2007 . 
 	 Euro-Par 2007: Parallel Processing. (LNCS 4641)
diff --git a/libstdc++-v3/doc/html/manual/profile_mode.html b/libstdc++-v3/doc/html/manual/profile_mode.html
index e47ecdb67e1..7a94336bf84 100644
--- a/libstdc++-v3/doc/html/manual/profile_mode.html
+++ b/libstdc++-v3/doc/html/manual/profile_mode.html
@@ -1,9 +1,9 @@
 
 
-Chapter 32. Profile Mode
                        Chapter 32. Profile Mode
                        Prev Part XII. 
+Chapter 32. Profile Mode
                        Chapter 32. Profile Mode
                        Prev Part XII. 
   Extensions
   
- Next
                        Chapter 32. Profile Mode
                        Table of Contents
                        Intro
                        Using the Profile Mode
                        Tuning the Profile Mode
                        Design
                        Wrapper Model
                        Instrumentation
                        Run Time Behavior
                        Analysis and Diagnostics
                        Cost Model
                        Reports
                        Testing
                        Extensions for Custom Containers
                        Empirical Cost Model
                        Implementation Issues
                        Stack Traces
                        Symbolization of Instruction Addresses
                        Concurrency
                        Using the Standard Library in the Instrumentation Implementation
                        Malloc Hooks
                        Construction and Destruction of Global Objects
                        Developer Information
                        Big Picture
                        How To Add A Diagnostic
                        Diagnostics
                        Diagnostic Template
                        Containers
                        Algorithms
                        Data Locality
                        Multithreaded Data Access
                        Statistics
                        Bibliography
                        Intro
                        
+
                        		 Next
                        Chapter 32. Profile Mode
                        Table of Contents
                        Intro
                        Using the Profile Mode
                        Tuning the Profile Mode
                        Design
                        Wrapper Model
                        Instrumentation
                        Run Time Behavior
                        Analysis and Diagnostics
                        Cost Model
                        Reports
                        Testing
                        Extensions for Custom Containers
                        Empirical Cost Model
                        Implementation Issues
                        Stack Traces
                        Symbolization of Instruction Addresses
                        Concurrency
                        Using the Standard Library in the Instrumentation Implementation
                        Malloc Hooks
                        Construction and Destruction of Global Objects
                        Developer Information
                        Big Picture
                        How To Add A Diagnostic
                        Diagnostics
                        Diagnostic Template
                        Containers
                        Algorithms
                        Data Locality
                        Multithreaded Data Access
                        Statistics
                        Bibliography
                        Intro
                        
   Goal: Give performance improvement advice based on
   recognition of suboptimal usage patterns of the standard library.
   
                        
@@ -16,25 +16,25 @@
    CGO 2009.
   
                        
   Strengths: 
-
                        • 
+
                          • 
   Unintrusive solution.  The application code does not require any 
   modification.
-  
                          •  The advice is call context sensitive, thus capable of
+  
                          •  The advice is call context sensitive, thus capable of
   identifying precisely interesting dynamic performance behavior.
-  
                          • 
+  
                          • 
   The overhead model is pay-per-view.  When you turn off a diagnostic class
   at compile time, its overhead disappears.
   
                          
   
                          
   Drawbacks: 
-
                          • 
+
                            • 
   You must recompile the application code with custom options.
-  
                            • You must run the application on representative input.
+  
                            • You must run the application on representative input.
   The advice is input dependent.
-  
                            • 
+  
                            • 
   The execution time will increase, in some cases by factors.
   
                            
-  
                            Using the Profile Mode
                            
+  
                            Using the Profile Mode
                            
   This is the anticipated common workflow for program foo.cc:
 
                             $ cat foo.cc
@@ -54,10 +54,10 @@ vector-size: improvement = 3: call stack = 0x804842c ...
 
                            
   
                            
   Anatomy of a warning:
-  
                            • 
+  
                              • 
   Warning id.  This is a short descriptive string for the class
   that this warning belongs to.  E.g., "vector-to-list".
-  
                              • 
+  
                              • 
   Estimated improvement.  This is an approximation of the benefit expected
   from implementing the change suggested by the warning.  It is given on
   a log10 scale.  Negative values mean that the alternative would actually
@@ -67,11 +67,11 @@ vector-size: improvement = 3: call stack = 0x804842c ...
   which is around 10e5.  The improvement from setting the initial size to
   1024 is in the range of 10e3, since the overhead of dynamic resizing is
   linear in this case.
-  
                              • 
+  
                              • 
   Call stack.  Currently, the addresses are printed without
   symbol name or code location attribution.
   Users are expected to postprocess the output using, for instance, addr2line.
-  
                              • 
+  
                              • 
   The warning message.  For some warnings, this is static text, e.g.,
   "change vector to list".  For other warnings, such as the one above,
   the message contains numeric advice, e.g., the suggested initial size
@@ -91,20 +91,20 @@ vector-size: improvement = 3: call stack = 0x804842c ...
   We believe such warnings can help users understand the performance
   behavior of their application better, which can lead to changes
   at a higher abstraction level.
-  
                              Tuning the Profile Mode
                              Compile time switches and environment variables (see also file
+  
                              Tuning the Profile Mode
                              Compile time switches and environment variables (see also file
    profiler.h).  Unless specified otherwise, they can be set at compile time
    using -D_<name> or by setting variable <name>
    in the environment where the program is run, before starting execution.
-  
                              • 
+  
                                • 
    [NO]_GLIBCXX_PROFILE_<diagnostic>:
    enable/disable specific diagnostics.
    See section Diagnostics for possible values.
    (Environment variables not supported.)
-   
                                • 
+   
                                • 
    GLIBCXX_PROFILE_TRACE_PATH_ROOT: set an alternative root
    path for the output files.
-   
                                • GLIBCXX_PROFILE_MAX_WARN_COUNT: set it to the maximum
-   number of warnings desired.  The default value is 10.
                                • 
+   
                                • GLIBCXX_PROFILE_MAX_WARN_COUNT: set it to the maximum
+   number of warnings desired.  The default value is 10.
                                • 
    GLIBCXX_PROFILE_MAX_STACK_DEPTH: if set to 0, 
    the advice will
    be collected and reported for the program as a whole, and not for each
@@ -112,21 +112,21 @@ vector-size: improvement = 3: call stack = 0x804842c ...
    This could also be used in continuous regression tests, where you
    just need to know whether there is a regression or not.
    The default value is 32.
-   
                                • 
+   
                                • 
    GLIBCXX_PROFILE_MEM_PER_DIAGNOSTIC:
    set a limit on how much memory to use for the accounting tables for each
    diagnostic type.  When this limit is reached, new events are ignored
    until the memory usage decreases under the limit.  Generally, this means
    that newly created containers will not be instrumented until some
    live containers are deleted.  The default is 128 MB.
-   
                                • 
+   
                                • 
    GLIBCXX_PROFILE_NOTHREADS:
    Make the library not use threads.  Otherwise, pthread mutexes are used
    to protect access to internal data structures.  This should be useful
    only if the program is single threaded and you want to avoid the overhead
    of aquiring/releasing locks unnecessarily.
    (Environment variable not supported.)
-   
                                • 
+   
                                • 
    HAVE_EXECINFO_H:
    This name should be defined at library configuration time.
    If your library was configured without execinfo.h, but
@@ -135,7 +135,7 @@ vector-size: improvement = 3: call stack = 0x804842c ...
    call context.
    (Environment variable not supported.)
    
                                
-  
                              Bibliography
                              
+  
                              Bibliography
                              
       Perflint: A Context Sensitive Performance Advisor for C++ Programs
     . Lixia Liu. Silvius Rus. Copyright © 2009 . 
 	Proceedings of the 2009 International Symposium on Code Generation
diff --git a/libstdc++-v3/doc/html/manual/sequences.html b/libstdc++-v3/doc/html/manual/sequences.html
index 1826bf16ac6..fd3ff148e54 100644
--- a/libstdc++-v3/doc/html/manual/sequences.html
+++ b/libstdc++-v3/doc/html/manual/sequences.html
@@ -1,9 +1,9 @@
 
 
-Chapter 16. Sequences
                              Chapter 16. Sequences
                              Prev Part VII. 
+Chapter 16. Sequences
                              Chapter 16. Sequences
                              Prev Part VII. 
   Containers
   
- Next
                              Chapter 16. Sequences
                              Table of Contents
                              list
                              list::size() is O(n)
                              vector
                              Space Overhead Management
                              list
                              list::size() is O(n)
                              
+
                              		 Next
                              Chapter 16. Sequences
                              Table of Contents
                              list
                              list::size() is O(n)
                              vector
                              Space Overhead Management
                              list
                              list::size() is O(n)
                              
      Yes it is, and that's okay.  This is a decision that we preserved
      when we imported SGI's STL implementation.  The following is
      quoted from their FAQ:
@@ -22,9 +22,9 @@
        themselves.
      
                              
        This choice is permitted by the C++ standard. The standard says
-       that size() “should” be constant time, and
-       “should” does not mean the same thing as
-       “shall”.  This is the officially recommended ISO
+       that size() “should” be constant time, and
+       “should” does not mean the same thing as
+       “shall”.  This is the officially recommended ISO
        wording for saying that an implementation is supposed to do
        something unless there is a good reason not to.
       
                              
diff --git a/libstdc++-v3/doc/html/manual/setup.html b/libstdc++-v3/doc/html/manual/setup.html
index 4d8f3d01172..684bd8ef629 100644
--- a/libstdc++-v3/doc/html/manual/setup.html
+++ b/libstdc++-v3/doc/html/manual/setup.html
@@ -1,9 +1,9 @@
 
 
-Chapter 2. Setup
                              Chapter 2. Setup
                              Prev Part I. 
+Chapter 2. Setup
                              Chapter 2. Setup
                              Prev Part I. 
   Introduction
   
- Next
                              Chapter 2. Setup
                              Table of Contents
                              Prerequisites
                              Configure
                              Make
                              To transform libstdc++ sources into installed include files
+
                              		 Next
                              Chapter 2. Setup
                              Table of Contents
                              Prerequisites
                              Configure
                              Make
                              To transform libstdc++ sources into installed include files
    and properly built binaries useful for linking to other software is
    a multi-step process. Steps include getting the sources,
    configuring and building the sources, testing, and installation.
@@ -19,7 +19,7 @@
    make install
    
                              
      Each step is described in more detail in the following sections.
-   
                              Prerequisites
                              
+   
                              Prerequisites
                              
   Because libstdc++ is part of GCC, the primary source for
    installation instructions is
    the GCC install page.
@@ -73,6 +73,8 @@ fr_FR@euro          ISO-8859-15
 is_IS               UTF-8
 it_IT               ISO-8859-1
 ja_JP.eucjp         EUC-JP
+ru_RU.ISO-8859-5    ISO-8859-5
+ru_RU.UTF-8         UTF-8
 se_NO.UTF-8         UTF-8
 ta_IN               UTF-8
 zh_TW               BIG5
@@ -86,16 +88,16 @@ zh_TW               BIG5
       necessary.
       
                              
 	To install support for locales, do only one of the following:
-      
                              • install all locales
                                • with RedHat Linux:
+      
                                  • install all locales
                                    • with RedHat Linux:
 	      
                                        export LC_ALL=C  
 	      
                                        rpm -e glibc-common --nodeps  
 	      
                                       
 		 rpm -i --define "_install_langs all"
 		 glibc-common-2.2.5-34.i386.rpm 
 		 
-	      
                                    • 
+	      
                                    • 
 	       Instructions for other operating systems solicited.
-	     
                                  • install just the necessary locales
                                    • with Debian Linux:
                                       Add the above list, as shown, to the file
-	      /etc/locale.gen 
                                       run /usr/sbin/locale-gen 
                                    • on most Unix-like operating systems:
                                       localedef -i de_DE -f ISO-8859-1 de_DE 
                                      (repeat for each entry in the above list) 
                                    • 
+	     
                                  • install just the necessary locales
                                    • with Debian Linux:
                                       Add the above list, as shown, to the file
+	      /etc/locale.gen 
                                       run /usr/sbin/locale-gen 
                                    • on most Unix-like operating systems:
                                       localedef -i de_DE -f ISO-8859-1 de_DE 
                                      (repeat for each entry in the above list) 
                                    • 
 	       Instructions for other operating systems solicited.
 	    
                              Prev Up Next
                              Bugs Home Configure
                              
diff --git a/libstdc++-v3/doc/html/manual/shared_ptr.html b/libstdc++-v3/doc/html/manual/shared_ptr.html
index 978c7ec54c6..35522568c1b 100644
--- a/libstdc++-v3/doc/html/manual/shared_ptr.html
+++ b/libstdc++-v3/doc/html/manual/shared_ptr.html
@@ -1,9 +1,9 @@
 
 
-shared_ptr
                              shared_ptr
                              Prev Chapter 11. Memory Next
                              shared_ptr
                              
+shared_ptr
                              shared_ptr
                              Prev Chapter 11. Memory Next
                              shared_ptr
                              
 The shared_ptr class template stores a pointer, usually obtained via new,
 and implements shared ownership semantics.
-
                              Requirements
                              
+
                              Requirements
                              
   
                              
     The standard deliberately doesn't require a reference-counted
     implementation, allowing other techniques such as a
@@ -15,7 +15,7 @@ and implements shared ownership semantics.
     shared_ptr in libstdc++ is derived from Boost's, so the same rules
     apply.
   
                               
-  
                              Design Issues
                              
+  
                              Design Issues
                              
 The shared_ptr code is kindly donated to GCC by the Boost
 project and the original authors of the code. The basic design and
 algorithms are from Boost, the notes below describe details specific to
@@ -29,7 +29,7 @@ drops to zero.
 Derived classes override those functions to destroy resources in a context
 where the correct dynamic type is known. This is an application of the
 technique known as type erasure.
-  
                              Implementation
                              Class Hierarchy
                              
+  
                              Implementation
                              Class Hierarchy
                              
 A shared_ptr<T> contains a pointer of
 type T* and an object of type
 __shared_count. The shared_count contains a
@@ -71,7 +71,7 @@ be forwarded to Tp's constructor.
 Unlike the other _Sp_counted_* classes, this one is parameterized on the
 type of object, not the type of pointer; this is purely a convenience
 that simplifies the implementation slightly.
-    
                              Thread Safety
                              
+    
                              Thread Safety
                              
 The interface of tr1::shared_ptr was extended for C++0x
 with support for rvalue-references and the other features from
 N2351. As with other libstdc++ headers shared by TR1 and C++0x,
@@ -129,7 +129,7 @@ compiler, standard library, platform etc. For the version of
 shared_ptr in libstdc++ the compiler and library are fixed, which
 makes things much simpler: we have an atomic CAS or we don't, see Lock
 Policy below for details.
-
                              Selecting Lock Policy
                               
+
                              Selecting Lock Policy
                               
     
                              
 There is a single _Sp_counted_base class,
 which is a template parameterized on the enum
@@ -145,7 +145,7 @@ specialization will be used. This design is necessary because it would
 not be conforming for shared_ptr to have an
 extra template parameter, even if it had a default value.  The
 available policies are:
-    
                              1. 
+    
                                1. 
        _S_Atomic
        
                                  
 Selected when GCC supports a builtin atomic compare-and-swap operation
@@ -153,13 +153,13 @@ on the target processor (see 
                                  
        _S_Mutex
        
                                  
 The _Sp_counted_base specialization for this policy contains a mutex,
 which is locked in add_ref_lock(). This policy is used when GCC's atomic
 builtins aren't available so explicit memory barriers are needed in places.
-       
                                2. 
+       
                                3. 
        _S_Single
        
                                  
 This policy uses a non-reentrant add_ref_lock() with no locking. It is
@@ -170,7 +170,7 @@ used when libstdc++ is built without --enable-threadsext/atomicity.h, which detect if the program
        is multi-threaded.  If only one thread of execution exists in
        the program then less expensive non-atomic operations are used.
-     
                                Dual C++0x and TR1 Implementation
                                
+     
                                Dual C++0x and TR1 Implementation
                                
 The classes derived from _Sp_counted_base (see Class Hierarchy
 below) and __shared_count are implemented separately for C++0x
 and TR1, in bits/boost_sp_shared_count.h and
@@ -181,7 +181,7 @@ The TR1 implementation is considered relatively stable, so is unlikely to
 change unless bug fixes require it.  If the code that is common to both
 C++0x and TR1 modes needs to diverge further then it might be necessary to 
 duplicate additional classes and only make changes to the C++0x versions.
-
                                Related functions and classes
                                dynamic_pointer_cast, static_pointer_cast,
+
                                Related functions and classes
                                dynamic_pointer_cast, static_pointer_cast,
 const_pointer_cast
                                
 As noted in N2351, these functions can be implemented non-intrusively using
 the alias constructor.  However the aliasing constructor is only available
@@ -214,10 +214,10 @@ is called.  Users should not try to use this.
 As well as the extra constructors, this implementation also needs some
 members of _Sp_counted_deleter to be protected where they could otherwise
 be private.
-    
                                Use
                                Examples
                                 
+    
                              Use
                              Examples
                               
       Examples of use can be found in the testsuite, under
       testsuite/tr1/2_general_utilities/shared_ptr.
-    
                              Unresolved Issues
                               
+    
                              Unresolved Issues
                               
       The resolution to C++ Standard Library issue 674,
       "shared_ptr interface changes for consistency with N1856" will
       need to be implemented after it is accepted into the working
@@ -260,12 +260,12 @@ be private.
       Exposing the alias constructor in TR1 mode could simplify the
       *_pointer_cast functions.  Constructor could be private in TR1
       mode, with the cast functions as friends.
-    
                              Acknowledgments
                               
+    
                              Acknowledgments
                               
     The original authors of the Boost shared_ptr, which is really nice
     code to work with, Peter Dimov in particular for his help and
     invaluable advice on thread safety.  Phillip Jordan and Paolo
     Carlini for the lock policy implementation.
-  
                              Bibliography
                              [
+  
                              Bibliography
                              [
       n2351
     ] 
       Improving shared_ptr for C++0x, Revision 2
@@ -274,7 +274,7 @@ be private.
     . 
       
       
-    . 
                              [
+    . 
                              [
       n2456
     ] 
       C++ Standard Library Active Issues List (Revision R52)
@@ -283,7 +283,7 @@ be private.
     . 
       
       
-    . 
                              [
+    . 
                              [
       n2461
     ] 
       Working Draft, Standard for Programming Language C++
@@ -292,7 +292,7 @@ be private.
     . 
       
       
-    . 
                              [
+    . 
                              [
       boostshared_ptr
     ] 
       Boost C++ Libraries documentation - shared_ptr class template
diff --git a/libstdc++-v3/doc/html/manual/source_code_style.html b/libstdc++-v3/doc/html/manual/source_code_style.html
index 392a345c825..8b9932cd032 100644
--- a/libstdc++-v3/doc/html/manual/source_code_style.html
+++ b/libstdc++-v3/doc/html/manual/source_code_style.html
@@ -1,14 +1,14 @@
 
 
-Coding Style
                              Coding Style
                              Prev Appendix A. 
+Coding Style
                              Coding Style
                              Prev Appendix A. 
   Contributing
   
- Next
                              Coding Style
                              
-  
                              Bad Identifiers
                              
+
                              		 Next
                              Coding Style
                              
+  
                              Bad Identifiers
                              
       Identifiers that conflict and should be avoided.
     

                              
-      This is the list of names “reserved to the
                              
-      implementation                              ” that have been claimed by certain
                              
+      This is the list of names “reserved to the
                              
+      implementation                              ”                               that have been claimed by certain
                              
       compilers and system headers of interest, and should not be used
                              
       in the library. It will grow, of course.  We generally are
                              
       interested in names that are not all-caps, except for those like
                              
@@ -192,7 +192,7 @@
       // long double conversion members mangled as __opr
                              
       // http://gcc.gnu.org/ml/libstdc++/1999-q4/msg00060.html
                              
       _opr
                              
-    
                              By Example

                              
+    
                              By Example

                              
       This library is written to appropriate C++ coding standards. As such,
                              
       it is intended to precede the recommendations of the GNU Coding
                              
       Standard, which can be referenced in full here:
                              
diff --git a/libstdc++-v3/doc/html/manual/source_design_notes.html b/libstdc++-v3/doc/html/manual/source_design_notes.html
index d1f6f920e1a..fcd30e59939 100644
--- a/libstdc++-v3/doc/html/manual/source_design_notes.html
+++ b/libstdc++-v3/doc/html/manual/source_design_notes.html
@@ -1,9 +1,9 @@
 
 
-Design Notes
                              Design Notes
                              Prev Appendix A. 
+Design Notes
                              Design Notes
                              Prev Appendix A. 
   Contributing
   
- Next
                              Design Notes
                              
+
                              		 Next
                              Design Notes
                              
   

                              
 
                              
     The Library
                              
diff --git a/libstdc++-v3/doc/html/manual/source_organization.html b/libstdc++-v3/doc/html/manual/source_organization.html
index b88511a9826..2ac9f9041a3 100644
--- a/libstdc++-v3/doc/html/manual/source_organization.html
+++ b/libstdc++-v3/doc/html/manual/source_organization.html
@@ -1,9 +1,9 @@
 
 
-Directory Layout and Source Conventions
                              Directory Layout and Source Conventions
                              Prev Appendix A. 
+Directory Layout and Source Conventions
                              Directory Layout and Source Conventions
                              Prev Appendix A. 
   Contributing
   
- Next
                              Directory Layout and Source Conventions
                              
+
                              		 Next
                              Directory Layout and Source Conventions
                              
     The unpacked source directory of libstdc++ contains the files
     needed to create the GNU C++ Library.
   

                              
diff --git a/libstdc++-v3/doc/html/manual/spine.html b/libstdc++-v3/doc/html/manual/spine.html
index 09f971a46e3..65e95f350be 100644
--- a/libstdc++-v3/doc/html/manual/spine.html
+++ b/libstdc++-v3/doc/html/manual/spine.html
@@ -1,13 +1,13 @@
 
 
-The GNU C++ Library
                              The GNU C++ Library
                              Prev   Next
                              The GNU C++ Library
                              Copyright © 2009 
+The GNU C++ Library
                              The GNU C++ Library
                              Prev   Next
                              The GNU C++ Library
                              Copyright © 2009 
       FSF
-    
                              Table of Contents
                              I. 
   Introduction
   
-
                              1. Status
                              Implementation Status
                              C++ 1998/2003
                              C++ TR1
                              C++ 200x
                              C++ TR 24733
                              License
                              The Code: GPL
                              The Documentation: GPL, FDL
                              Bugs
                              Implementation Bugs
                              Standard Bugs
                              2. Setup
                              Prerequisites
                              Configure
                              Make
                              3. Using
                              Linking Library Binary Files
                              Headers
                              Header Files
                              Mixing Headers
                              The C Headers and namespace std
                              Precompiled Headers
                              Namespaces
                              Available Namespaces
                              namespace std
                              Using Namespace Composition
                              Macros
                              Concurrency
                              Prerequisites
                              Thread Safety
                              Atomics
                              IO
                              Containers
                              Exceptions
                              Exception Safety
                              Exception Neutrality
                              Doing without
                              Compatibility
                              Debugging Support
                              Using g++
                              Debug Versions of Library Binary Files
                              Memory Leak Hunting
                              Using gdb
                              Tracking uncaught exceptions
                              Debug Mode
                              Compile Time Checking
                              Profile-based Performance Analysis
                              II. 
+
                              1. Status
                              Implementation Status
                              C++ 1998/2003
                              C++ 200x
                              C++ TR1
                              C++ TR 24733
                              License
                              The Code: GPL
                              The Documentation: GPL, FDL
                              Bugs
                              Implementation Bugs
                              Standard Bugs
                              2. Setup
                              Prerequisites
                              Configure
                              Make
                              3. Using
                              Linking Library Binary Files
                              Headers
                              Header Files
                              Mixing Headers
                              The C Headers and namespace std
                              Precompiled Headers
                              Namespaces
                              Available Namespaces
                              namespace std
                              Using Namespace Composition
                              Macros
                              Concurrency
                              Prerequisites
                              Thread Safety
                              Atomics
                              IO
                              Containers
                              Exceptions
                              Exception Safety
                              Exception Neutrality
                              Doing without
                              Compatibility
                              Debugging Support
                              Using g++
                              Debug Versions of Library Binary Files
                              Memory Leak Hunting
                              Using gdb
                              Tracking uncaught exceptions
                              Debug Mode
                              Compile Time Checking
                              Profile-based Performance Analysis
                              II. 
   Support
   
 
                              4. Types
                              Fundamental Types
                              Numeric Properties
                              NULL
                              5. Dynamic Memory
                              6. Termination
                              Termination Handlers
                              Verbose Terminate Handler
                              III. 
@@ -31,7 +31,7 @@
 
                              19. Predefined
                              Iterators vs. Pointers
                              One Past the End
                              IX. 
   Algorithms
   
-
                              20. Mutating
                              swap
                              Specializations
                              X. 
+
                              20. Mutating
                              swap
                              Specializations
                              X. 
   Numerics
   
 
                              21. Complex
                              complex Processing
                              22. Generalized Operations
                              23. Interacting with C
                              Numerics vs. Arrays
                              C99
                              XI. 
@@ -46,12 +46,12 @@
 
                              Contributor Checklist
                              Reading
                              Assignment
                              Getting Sources
                              Submitting Patches
                              Directory Layout and Source Conventions
                              Coding Style
                              Bad Identifiers
                              By Example
                              Documentation Style
                              Doxygen
                              Docbook
                              Design Notes
                              B. 
   Porting and Maintenance
   
-
                              Configure and Build Hacking
                              Prerequisites
                              Overview: What Comes from Where
                              Storing Information in non-AC files (like configure.host)
                              Coding and Commenting Conventions
                              The acinclude.m4 layout
                              GLIBCXX_ENABLE, the --enable maker
                              Porting to New Hardware or Operating Systems
                              Operating System
                              CPU
                              Character Types
                              Thread Safety
                              Numeric Limits
                              Libtool
                              Test
                              Organization
                              Running the Testsuite
                              Writing a new test case
                              Test Harness and Utilities
                              ABI Policy and Guidelines
                              The C++ Interface
                              Versioning
                              Allowed Changes
                              Prohibited Changes
                              Implementation
                              Testing
                              Outstanding Issues
                              API Evolution and Deprecation History
                              3.0
                              3.1
                              3.2
                              3.3
                              3.4
                              4.0
                              4.1
                              4.2
                              4.3
                              Backwards Compatibility
                              First
                              Second
                              Third
                              C. 
+
                              Configure and Build Hacking
                              Prerequisites
                              Overview: What Comes from Where
                              Storing Information in non-AC files (like configure.host)
                              Coding and Commenting Conventions
                              The acinclude.m4 layout
                              GLIBCXX_ENABLE, the --enable maker
                              Porting to New Hardware or Operating Systems
                              Operating System
                              CPU
                              Character Types
                              Thread Safety
                              Numeric Limits
                              Libtool
                              Test
                              Organization
                              Running the Testsuite
                              Writing a new test case
                              Test Harness and Utilities
                              Special Topics
                              ABI Policy and Guidelines
                              The C++ Interface
                              Versioning
                              Allowed Changes
                              Prohibited Changes
                              Implementation
                              Testing
                              Outstanding Issues
                              API Evolution and Deprecation History
                              3.0
                              3.1
                              3.2
                              3.3
                              3.4
                              4.0
                              4.1
                              4.2
                              4.3
                              4.4
                              4.5
                              Backwards Compatibility
                              First
                              Second
                              Third
                              C. 
   Free Software Needs Free Documentation
   
 
                              D. 
-    GNU General Public License version 3
-  
                              E. GNU Free Documentation License
                              Index
                              List of Tables
                              1.1. C++ 1998/2003 Implementation Status
                              1.2. C++ TR1 Implementation Status
                              1.3. C++ 200x Implementation Status
                              1.4. C++ TR 24733 Implementation Status
                              3.1. C++ 1998 Library Headers
                              3.2. C++ 1998 Library Headers for C Library Facilities
                              3.3. C++ 200x Library Headers
                              3.4. C++ 200x Library Headers for C Library Facilities
                              3.5. C++ TR 1 Library Headers
                              3.6. C++ TR 1 Library Headers for C Library Facilities
                              3.7. C++ TR 24733 Decimal Floating-Point Header
                              3.8. C++ ABI Headers
                              3.9. Extension Headers
                              3.10. Extension Debug Headers
                              3.11. Extension Profile Headers
                              3.12. Extension Parallel Headers
                              30.1. Debugging Containers
                              30.2. Debugging Containers C++0x
                              31.1. Parallel Algorithms
                              32.1. Code Location
                              32.2. Diagnostics
                              33.1. Bitmap Allocator Memory Map
                              A.1. HTML to Docbook XML markup comparison
                              A.2. Docbook XML Element Use
                              B.1. Extension Allocators
                              B.2. Extension Allocators Continued
                              Prev   Next
                              The GNU C++ Library Documentation Home Part I. 
+    GNU General Public License version 3
+  
                              E. GNU Free Documentation License
                              Index
                              List of Tables
                              1.1. C++ 1998/2003 Implementation Status
                              1.2. C++ 200x Implementation Status
                              1.3. C++ TR1 Implementation Status
                              1.4. C++ TR 24733 Implementation Status
                              3.1. C++ 1998 Library Headers
                              3.2. C++ 1998 Library Headers for C Library Facilities
                              3.3. C++ 200x Library Headers
                              3.4. C++ 200x Library Headers for C Library Facilities
                              3.5. C++ TR 1 Library Headers
                              3.6. C++ TR 1 Library Headers for C Library Facilities
                              3.7. C++ TR 24733 Decimal Floating-Point Header
                              3.8. C++ ABI Headers
                              3.9. Extension Headers
                              3.10. Extension Debug Headers
                              3.11. Extension Profile Headers
                              3.12. Extension Parallel Headers
                              30.1. Debugging Containers
                              30.2. Debugging Containers C++0x
                              31.1. Parallel Algorithms
                              32.1. Code Location
                              32.2. Diagnostics
                              33.1. Bitmap Allocator Memory Map
                              A.1. HTML to Docbook XML markup comparison
                              A.2. Docbook XML Element Use
                              B.1. Extension Allocators
                              B.2. Extension Allocators Continued
                              Prev   Next
                              The GNU C++ Library Documentation Home Part I. 
   Introduction
   
 
                              
diff --git a/libstdc++-v3/doc/html/manual/status.html b/libstdc++-v3/doc/html/manual/status.html
index 40dc1a26eb2..25cef369d53 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -1,14 +1,14 @@
 
 
-Chapter 1. Status
                              Chapter 1. Status
                              Prev Part I. 
+Chapter 1. Status
                              Chapter 1. Status
                              Prev Part I. 
   Introduction
   
- Next
                              Chapter 1. Status
                              Table of Contents
                              Implementation Status
                              C++ 1998/2003
                              C++ TR1
                              C++ 200x
                              C++ TR 24733
                              License
                              The Code: GPL
                              The Documentation: GPL, FDL
                              Bugs
                              Implementation Bugs
                              Standard Bugs
                              Implementation Status
                              C++ 1998/2003
                              Implementation Status
                              
+
                              		 Next
                              Chapter 1. Status
                              Table of Contents
                              Implementation Status
                              C++ 1998/2003
                              C++ 200x
                              C++ TR1
                              C++ TR 24733
                              License
                              The Code: GPL
                              The Documentation: GPL, FDL
                              Bugs
                              Implementation Bugs
                              Standard Bugs
                              Implementation Status
                              C++ 1998/2003
                              Implementation Status
                              
 This status table is based on the table of contents of ISO/IEC 14882:2003.
 
                              
 This page describes the C++0x support in mainline GCC SVN, not in any
 particular release.
-
                              Table 1.1. C++ 1998/2003 Implementation Status
                              SectionDescriptionStatusComments
                              
+
                              Table 1.1. C++ 1998/2003 Implementation Status
                              SectionDescriptionStatusComments
                              
 	18
       
 	Language support
@@ -52,7 +52,7 @@ particular release.
       	Appendix D
       
 	Compatibility features
-      
                              D.1Increment operator with bool operand  
                              D.2static keyword  
                              D.3Access declarations  
                              D.4Implicit conversion from const strings  
                              D.5C standard library headers  
                              D.6Old iostreams members  
                              D.7char* streams  

                              Implementation Specific Behavior
                              
+      
                              D.1Increment operator with bool operand  
                              D.2static keyword  
                              D.3Access declarations  
                              D.4Implicit conversion from const strings  
                              D.5C standard library headers  
                              D.6Old iostreams members  
                              D.7char* streams  

                              Implementation Specific Behavior
                              
      The ISO standard defines the following phrase:
    
                              
 	 [1.3.5] implementation-defined behavior
@@ -142,23 +142,7 @@ particular release.
       in this chapter.
    
                              [27.8.1.4]/16 Calling fstream::sync when
       a get area exists will... whatever fflush() does, I think.
-   
                              C++ TR1
                              
-This table is based on the table of contents of ISO/IEC DTR 19768
-Doc No: N1836=05-0096 Date: 2005-06-24
-Draft Technical Report on C++ Library Extensions
-
                              
-In this implementation the header names are prefixed by
-tr1/, for instance <tr1/functional>,
-<tr1/memory>, and so on.
-
                              
-This page describes the TR1 support in mainline GCC SVN, not in any particular
-release.
-
                              Table 1.2. C++ TR1 Implementation Status
                              SectionDescriptionStatusComments
                              2General Utilities
                              2.1Reference wrappers  
                              2.1.1Additions to header <functional> synopsisY 
                              2.1.2Class template reference_wrapper  
                              2.1.2.1reference_wrapper construct/copy/destroyY 
                              2.1.2.2reference_wrapper assignmentY 
                              2.1.2.3reference_wrapper accessY 
                              2.1.2.4reference_wrapper invocationY 
                              2.1.2.5reference_wrapper helper functionsY 
                              2.2Smart pointers  
                              2.2.1Additions to header <memory> synopsisY 
                              2.2.2Class bad_weak_ptrY 
                              2.2.3Class template shared_ptr 
-	
                              
-	  Uses code from
-	  boost::shared_ptr.
-	
                                
-      
                              2.2.3.1shared_ptr constructorsY 
                              2.2.3.2shared_ptr destructorY 
                              2.2.3.3shared_ptr assignmentY 
                              2.2.3.4shared_ptr modifiersY 
                              2.2.3.5shared_ptr observersY 
                              2.2.3.6shared_ptr comparisonY 
                              2.2.3.7shared_ptr I/OY 
                              2.2.3.8shared_ptr specialized algorithmsY 
                              2.2.3.9shared_ptr castsY 
                              2.2.3.10get_deleterY 
                              2.2.4Class template weak_ptr  
                              2.2.4.1weak_ptr constructorsY 
                              2.2.4.2weak_ptr destructorY 
                              2.2.4.3weak_ptr assignmentY 
                              2.2.4.4weak_ptr modifiersY 
                              2.2.4.5weak_ptr observersY 
                              2.2.4.6weak_ptr comparisonY 
                              2.2.4.7weak_ptr specialized algorithmsY 
                              2.2.5Class template enable_shared_from_thisY 
                              3Function Objects
                              3.1DefinitionsY 
                              3.2Additions to <functional> synopsisY 
                              3.3RequirementsY 
                              3.4Function return typesY 
                              3.5Function template mem_fnY 
                              3.6Function object binders  
                              3.6.1Class template is_bind_expressionY 
                              3.6.2Class template is_placeholderY 
                              3.6.3Function template bindY 
                              3.6.4PlaceholdersY 
                              3.7Polymorphic function wrappers  
                              3.7.1Class bad_function_callY 
                              3.7.1.1bad_function_call constructorY 
                              3.7.2Class template function  
                              3.7.2.1function construct/copy/destroyY 
                              3.7.2.2function modifiersY 
                              3.7.2.3function capacityY 
                              3.7.2.4function invocationY 
                              3.7.2.5function target accessY 
                              3.7.2.6undefined operatorsY 
                              3.7.2.7null pointer comparison operatorsY 
                              3.7.2.8specialized algorithmsY 
                              4Metaprogramming and type traits
                              4.1RequirementsY 
                              4.2Header <type_traits> synopsisY 
                              4.3Helper classesY 
                              4.4General RequirementsY 
                              4.5Unary Type Traits  
                              4.5.1Primary Type CategoriesY 
                              4.5.2Composite type traitsY 
                              4.5.3Type propertiesY 
                              4.6Relationships between typesY 
                              4.7Transformations between types  
                              4.7.1Const-volatile modificationsY 
                              4.7.2Reference modificationsY 
                              4.7.3Array modificationsY 
                              4.7.4Pointer modificationsY 
                              4.8Other transformationsY 
                              4.9Implementation requirementsY 
                              5Numerical Facilities
                              5.1Random number generation  
                              5.1.1RequirementsY 
                              5.1.2Header <random> synopsisY 
                              5.1.3Class template variate_generatorY 
                              5.1.4Random number engine class templatesY 
                              5.1.4.1Class template linear_congruentialY 
                              5.1.4.2Class template mersenne_twisterY 
                              5.1.4.3Class template subtract_with_carryY 
                              5.1.4.4Class template subtract_with_carry_01Y 
                              5.1.4.5Class template discard_blockY 
                              5.1.4.6Class template xor_combineYoperator()() per N2079
                              5.1.5Engines with predefined parametersY 
                              5.1.6Class random_deviceY 
                              5.1.7Random distribution class templatesY 
                              5.1.7.1Class template uniform_intY 
                              5.1.7.2Class bernoulli_distributionY 
                              5.1.7.3Class template geometric_distributionY 
                              5.1.7.4Class template poisson_distributionY 
                              5.1.7.5Class template binomial_distributionY 
                              5.1.7.6Class template uniform_realY 
                              5.1.7.7Class template exponential_distributionY 
                              5.1.7.8Class template normal_distributionY 
                              5.1.7.9Class template gamma_distributionY 
                              5.2Mathematical special functionsY 
                              5.2.1Additions to header <cmath> synopsisY 
                              5.2.1.1associated Laguerre polynomialsY 
                              5.2.1.2associated Legendre functionsY 
                              5.2.1.3beta functionY 
                              5.2.1.4(complete) elliptic integral of the first kindY 
                              5.2.1.5(complete) elliptic integral of the second kindY 
                              5.2.1.6(complete) elliptic integral of the third kindY 
                              5.2.1.7confluent hypergeometric functionsY 
                              5.2.1.8regular modified cylindrical Bessel functionsY 
                              5.2.1.9cylindrical Bessel functions (of the first kind)Y 
                              5.2.1.10irregular modified cylindrical Bessel functionsY 
                              5.2.1.11cylindrical Neumann functionsY 
                              5.2.1.12(incomplete) elliptic integral of the first kindY 
                              5.2.1.13(incomplete) elliptic integral of the second kindY 
                              5.2.1.14(incomplete) elliptic integral of the third kindY 
                              5.2.1.15exponential integralY 
                              5.2.1.16Hermite polynomialsY 
                              5.2.1.17hypergeometric functionsY 
                              5.2.1.18Laguerre polynomialsY 
                              5.2.1.19Legendre polynomialsY 
                              5.2.1.20Riemann zeta functionY 
                              5.2.1.21spherical Bessel functions (of the first kind)Y 
                              5.2.1.22spherical associated Legendre functionsY 
                              5.2.1.23spherical Neumann functionsY 
                              5.2.2Additions to header <math.h> synopsisY 
                              6Containers
                              6.1Tuple typesY 
                              6.1.1Header <tuple> synopsisY 
                              6.1.2Additions to header <utility> synopsisY 
                              6.1.3Class template tupleY 
                              6.1.3.1ConstructionY 
                              6.1.3.2Tuple creation functionsY 
                              6.1.3.3Tuple helper classesY 
                              6.1.3.4Element accessY 
                              6.1.3.5Relational operatorsY 
                              6.1.4PairsY 
                              6.2Fixed size arrayY 
                              6.2.1Header <array> synopsisY 
                              6.2.2Class template arrayY 
                              6.2.2.1array constructors, copy, and assignmentY 
                              6.2.2.2array specialized algorithmsY 
                              6.2.2.3array sizeY 
                              6.2.2.4Zero sized arraysY 
                              6.2.2.5Tuple interface to class template arrayY 
                              6.3Unordered associative containersY 
                              6.3.1Unordered associative container requirementsY 
                              6.3.1.1Exception safety guaranteesY 
                              6.3.2Additions to header <functional> synopsisY 
                              6.3.3Class template hashY 
                              6.3.4Unordered associative container classesY 
                              6.3.4.1Header <unordered_set> synopsisY 
                              6.3.4.2Header <unordered_map> synopsisY 
                              6.3.4.3Class template unordered_setY 
                              6.3.4.3.1unordered_set constructorsY 
                              6.3.4.3.2unordered_set swapY 
                              6.3.4.4Class template unordered_mapY 
                              6.3.4.4.1unordered_map constructorsY 
                              6.3.4.4.2unordered_map element accessY 
                              6.3.4.4.3unordered_map swapY 
                              6.3.4.5Class template unordered_multisetY 
                              6.3.4.5.1unordered_multiset constructorsY 
                              6.3.4.5.2unordered_multiset swapY 
                              6.3.4.6Class template unordered_multimapY 
                              6.3.4.6.1unordered_multimap constructorsY 
                              6.3.4.6.2unordered_multimap swapY 
                              7Regular Expressions
                              7.1DefinitionsN 
                              7.2RequirementsN 
                              7.3Regular expressions summaryN 
                              7.4Header <regex> synopsisN 
                              7.5Namespace tr1::regex_constantsN 
                              7.5.1Bitmask Type syntax_option_typeN 
                              7.5.2Bitmask Type regex_constants::match_flag_typeN 
                              7.5.3Implementation defined error_typeN 
                              7.6Class regex_errorN 
                              7.7Class template regex_traitsN 
                              7.8Class template basic_regexN 
                              7.8.1basic_regex constantsN 
                              7.8.2basic_regex constructorsN 
                              7.8.3basic_regex assignN 
                              7.8.4basic_regex constant operationsN 
                              7.8.5basic_regex localeN 
                              7.8.6basic_regex swapN 
                              7.8.7basic_regex non-member functionsN 
                              7.8.7.1basic_regex non-member swapN 
                              7.9Class template sub_matchN 
                              7.9.1sub_match membersN 
                              7.9.2sub_match non-member operatorsN 
                              7.10Class template match_resultsN 
                              7.10.1match_results constructorsN 
                              7.10.2match_results sizeN 
                              7.10.3match_results element accessN 
                              7.10.4match_results formattingN 
                              7.10.5match_results allocatorN 
                              7.10.6match_results swapN 
                              7.11Regular expression algorithmsN 
                              7.11.1exceptionsN 
                              7.11.2regex_matchN 
                              7.11.3regex_searchN 
                              7.11.4regex_replaceN 
                              7.12Regular expression IteratorsN 
                              7.12.1Class template regex_iteratorN 
                              7.12.1.1regex_iterator constructorsN 
                              7.12.1.2regex_iterator comparisonsN 
                              7.12.1.3regex_iterator dereferenceN 
                              7.12.1.4regex_iterator incrementN 
                              7.12.2Class template regex_token_iteratorN 
                              7.12.2.1regex_token_iterator constructorsN 
                              7.12.2.2regex_token_iterator comparisonsN 
                              7.12.2.3regex_token_iterator dereferenceN 
                              7.12.2.4regex_token_iterator incrementN 
                              7.13Modified ECMAScript regular expression grammarN 
                              8C Compatibility
                              8.1Additions to header <complex>Y 
                              8.1.1SynopsisY 
                              8.1.2Function acosY 
                              8.1.3Function asinY 
                              8.1.4Function atanY 
                              8.1.5Function acoshY 
                              8.1.6Function asinhY 
                              8.1.7Function atanhY 
                              8.1.8Function fabsY 
                              8.1.9Additional OverloadsY 
                              8.2Header <ccomplex>NDR 551
                              8.3Header <complex.h>NDR 551
                              8.4Additions to header <cctype>Y 
                              8.4.1SynopsisY 
                              8.4.2Function isblankY 
                              8.5Additions to header <ctype.h>Y 
                              8.6Header <cfenv>Y 
                              8.6.1SynopsisY 
                              8.6.2DefinitionsY 
                              8.7Header <fenv.h>Y 
                              8.8Additions to header <cfloat>Y 
                              8.9Additions to header <float.h>Y 
                              8.10Additions to header <ios>N 
                              8.10.1SynopsisN 
                              8.10.2Function hexfloatN 
                              8.11Header <cinttypes>Y 
                              8.11.1SynopsisYDR 557
                              8.11.2DefinitionsY 
                              8.12Header <inttypes.h>Y 
                              8.13Additions to header <climits>Y 
                              8.14Additions to header <limits.h>Y 
                              8.15Additions to header <locale>N 
                              8.16Additions to header <cmath>Y 
                              8.16.1SynopsisY 
                              8.16.2DefinitionsY 
                              8.16.3Function template definitionsY 
                              8.16.4Additional overloadsYDR 568; DR 550
                              8.17Additions to header <math.h>Y 
                              8.18Additions to header <cstdarg>Y 
                              8.19Additions to header <stdarg.h>Y 
                              8.20The header <cstdbool>Y 
                              8.21The header <stdbool.h>Y 
                              8.22The header <cstdint>Y 
                              8.22.1SynopsisY 
                              8.22.2DefinitionsY 
                              8.23The header <stdint.h>Y 
                              8.24Additions to header <cstdio>Y 
                              8.24.1SynopsisY 
                              8.24.2DefinitionsY 
                              8.24.3Additional format specifiersYC library dependency
                              8.24.4Additions to header <stdio.h>Y 
                              8.25Additions to header <cstdlib>Y 
                              8.25.1SynopsisY 
                              8.25.2DefinitionsY 
                              8.25.3Function absY 
                              8.25.4Function divY 
                              8.26Additions to header <stdlib.h>Y 
                              8.27Header <ctgmath>YDR 551
                              8.28Header <tgmath.h>YDR 551
                              8.29Additions to header <ctime>YC library dependency
                              8.30Additions to header <cwchar>Y 
                              8.30.1SynopsisY 
                              8.30.2DefinitionsY 
                              8.30.3Additional wide format specifiersYC library dependency
                              8.31Additions to header <wchar.h>Y 
                              8.32Additions to header <cwctype>Y 
                              8.32.1SynopsisY 
                              8.32.2Function iswblankY 
                              8.33Additions to header <wctype.h>Y 

                              C++ 200x
                              
+   
                              C++ 200x
                              
 This table is based on the table of contents of ISO/IEC 
 Doc No: N2857=09-0047 Date: 2009-03-23
 Working Draft, Standard for Programming Language C++
@@ -171,7 +155,7 @@ presence of the required flag.
 
                              
 This page describes the C++0x support in mainline GCC SVN, not in any
 particular release.
-
                              Table 1.3. C++ 200x Implementation Status
                              SectionDescriptionStatusComments
                              
+
                              Table 1.2. C++ 200x Implementation Status
                              SectionDescriptionStatusComments
                              
 	18
       
 	Language support
@@ -224,7 +208,7 @@ particular release.
 	29
       
 	Atomic operations
-      
                              29.1GeneralY 
                              29.2Header <cstdatomic> synopsisY 
                              29.3Order and consistencyN 
                              29.4Lock-free propertyYBased on _GLIBCXX_ATOMIC_PROPERTY
                              29.5Atomic types  
                              29.5.1Integral typesYMissing constexpr
                              29.5.2Address typesYMissing constexpr
                              29.5.3Generic typesYMissing constexpr
                              29.6Operations on atomic typesY 
                              29.7Flag Type and operationsY 
                              29.8FencesN 
                              
+      
                              29.1GeneralY 
                              29.2Header <atomic> synopsisY 
                              29.3Order and consistencyN 
                              29.4Lock-free propertyYBased on _GLIBCXX_ATOMIC_PROPERTY
                              29.5Atomic types  
                              29.5.1Integral typesYMissing constexpr
                              29.5.2Address typesYMissing constexpr
                              29.5.3Generic typesYMissing constexpr
                              29.6Operations on atomic typesY 
                              29.7Flag Type and operationsY 
                              29.8FencesN 
                              
 	30
       
 	Thread support
@@ -232,7 +216,23 @@ particular release.
       	Appendix D
       
 	Compatibility features
-      
                              D.1Increment operator with bool operand  
                              D.2static keyword  
                              D.3Access declarations  
                              D.4Implicit conversion from const strings  
                              D.5C standard library headers  
                              D.6Old iostreams members  
                              D.7char* streams  
                              D.8Binders  
                              D.9auto_ptr  
                              D.10Iterator primitives  

                              C++ TR 24733
                              
+      
                              D.1Increment operator with bool operand  
                              D.2static keyword  
                              D.3Access declarations  
                              D.4Implicit conversion from const strings  
                              D.5C standard library headers  
                              D.6Old iostreams members  
                              D.7char* streams  
                              D.8Binders  
                              D.9auto_ptr  
                              D.10Iterator primitives  

                              C++ TR1
                              
+This table is based on the table of contents of ISO/IEC DTR 19768
+Doc No: N1836=05-0096 Date: 2005-06-24
+Draft Technical Report on C++ Library Extensions
+
                              
+In this implementation the header names are prefixed by
+tr1/, for instance <tr1/functional>,
+<tr1/memory>, and so on.
+
                              
+This page describes the TR1 support in mainline GCC SVN, not in any particular
+release.
+
                              Table 1.3. C++ TR1 Implementation Status
                              SectionDescriptionStatusComments
                              2General Utilities
                              2.1Reference wrappers  
                              2.1.1Additions to header <functional> synopsisY 
                              2.1.2Class template reference_wrapper  
                              2.1.2.1reference_wrapper construct/copy/destroyY 
                              2.1.2.2reference_wrapper assignmentY 
                              2.1.2.3reference_wrapper accessY 
                              2.1.2.4reference_wrapper invocationY 
                              2.1.2.5reference_wrapper helper functionsY 
                              2.2Smart pointers  
                              2.2.1Additions to header <memory> synopsisY 
                              2.2.2Class bad_weak_ptrY 
                              2.2.3Class template shared_ptr 
+	
                              
+	  Uses code from
+	  boost::shared_ptr.
+	
                                
+      
                              2.2.3.1shared_ptr constructorsY 
                              2.2.3.2shared_ptr destructorY 
                              2.2.3.3shared_ptr assignmentY 
                              2.2.3.4shared_ptr modifiersY 
                              2.2.3.5shared_ptr observersY 
                              2.2.3.6shared_ptr comparisonY 
                              2.2.3.7shared_ptr I/OY 
                              2.2.3.8shared_ptr specialized algorithmsY 
                              2.2.3.9shared_ptr castsY 
                              2.2.3.10get_deleterY 
                              2.2.4Class template weak_ptr  
                              2.2.4.1weak_ptr constructorsY 
                              2.2.4.2weak_ptr destructorY 
                              2.2.4.3weak_ptr assignmentY 
                              2.2.4.4weak_ptr modifiersY 
                              2.2.4.5weak_ptr observersY 
                              2.2.4.6weak_ptr comparisonY 
                              2.2.4.7weak_ptr specialized algorithmsY 
                              2.2.5Class template enable_shared_from_thisY 
                              3Function Objects
                              3.1DefinitionsY 
                              3.2Additions to <functional> synopsisY 
                              3.3RequirementsY 
                              3.4Function return typesY 
                              3.5Function template mem_fnY 
                              3.6Function object binders  
                              3.6.1Class template is_bind_expressionY 
                              3.6.2Class template is_placeholderY 
                              3.6.3Function template bindY 
                              3.6.4PlaceholdersY 
                              3.7Polymorphic function wrappers  
                              3.7.1Class bad_function_callY 
                              3.7.1.1bad_function_call constructorY 
                              3.7.2Class template function  
                              3.7.2.1function construct/copy/destroyY 
                              3.7.2.2function modifiersY 
                              3.7.2.3function capacityY 
                              3.7.2.4function invocationY 
                              3.7.2.5function target accessY 
                              3.7.2.6undefined operatorsY 
                              3.7.2.7null pointer comparison operatorsY 
                              3.7.2.8specialized algorithmsY 
                              4Metaprogramming and type traits
                              4.1RequirementsY 
                              4.2Header <type_traits> synopsisY 
                              4.3Helper classesY 
                              4.4General RequirementsY 
                              4.5Unary Type Traits  
                              4.5.1Primary Type CategoriesY 
                              4.5.2Composite type traitsY 
                              4.5.3Type propertiesY 
                              4.6Relationships between typesY 
                              4.7Transformations between types  
                              4.7.1Const-volatile modificationsY 
                              4.7.2Reference modificationsY 
                              4.7.3Array modificationsY 
                              4.7.4Pointer modificationsY 
                              4.8Other transformationsY 
                              4.9Implementation requirementsY 
                              5Numerical Facilities
                              5.1Random number generation  
                              5.1.1RequirementsY 
                              5.1.2Header <random> synopsisY 
                              5.1.3Class template variate_generatorY 
                              5.1.4Random number engine class templatesY 
                              5.1.4.1Class template linear_congruentialY 
                              5.1.4.2Class template mersenne_twisterY 
                              5.1.4.3Class template subtract_with_carryY 
                              5.1.4.4Class template subtract_with_carry_01Y 
                              5.1.4.5Class template discard_blockY 
                              5.1.4.6Class template xor_combineYoperator()() per N2079
                              5.1.5Engines with predefined parametersY 
                              5.1.6Class random_deviceY 
                              5.1.7Random distribution class templatesY 
                              5.1.7.1Class template uniform_intY 
                              5.1.7.2Class bernoulli_distributionY 
                              5.1.7.3Class template geometric_distributionY 
                              5.1.7.4Class template poisson_distributionY 
                              5.1.7.5Class template binomial_distributionY 
                              5.1.7.6Class template uniform_realY 
                              5.1.7.7Class template exponential_distributionY 
                              5.1.7.8Class template normal_distributionY 
                              5.1.7.9Class template gamma_distributionY 
                              5.2Mathematical special functionsY 
                              5.2.1Additions to header <cmath> synopsisY 
                              5.2.1.1associated Laguerre polynomialsY 
                              5.2.1.2associated Legendre functionsY 
                              5.2.1.3beta functionY 
                              5.2.1.4(complete) elliptic integral of the first kindY 
                              5.2.1.5(complete) elliptic integral of the second kindY 
                              5.2.1.6(complete) elliptic integral of the third kindY 
                              5.2.1.7confluent hypergeometric functionsY 
                              5.2.1.8regular modified cylindrical Bessel functionsY 
                              5.2.1.9cylindrical Bessel functions (of the first kind)Y 
                              5.2.1.10irregular modified cylindrical Bessel functionsY 
                              5.2.1.11cylindrical Neumann functionsY 
                              5.2.1.12(incomplete) elliptic integral of the first kindY 
                              5.2.1.13(incomplete) elliptic integral of the second kindY 
                              5.2.1.14(incomplete) elliptic integral of the third kindY 
                              5.2.1.15exponential integralY 
                              5.2.1.16Hermite polynomialsY 
                              5.2.1.17hypergeometric functionsY 
                              5.2.1.18Laguerre polynomialsY 
                              5.2.1.19Legendre polynomialsY 
                              5.2.1.20Riemann zeta functionY 
                              5.2.1.21spherical Bessel functions (of the first kind)Y 
                              5.2.1.22spherical associated Legendre functionsY 
                              5.2.1.23spherical Neumann functionsY 
                              5.2.2Additions to header <math.h> synopsisY 
                              6Containers
                              6.1Tuple typesY 
                              6.1.1Header <tuple> synopsisY 
                              6.1.2Additions to header <utility> synopsisY 
                              6.1.3Class template tupleY 
                              6.1.3.1ConstructionY 
                              6.1.3.2Tuple creation functionsY 
                              6.1.3.3Tuple helper classesY 
                              6.1.3.4Element accessY 
                              6.1.3.5Relational operatorsY 
                              6.1.4PairsY 
                              6.2Fixed size arrayY 
                              6.2.1Header <array> synopsisY 
                              6.2.2Class template arrayY 
                              6.2.2.1array constructors, copy, and assignmentY 
                              6.2.2.2array specialized algorithmsY 
                              6.2.2.3array sizeY 
                              6.2.2.4Zero sized arraysY 
                              6.2.2.5Tuple interface to class template arrayY 
                              6.3Unordered associative containersY 
                              6.3.1Unordered associative container requirementsY 
                              6.3.1.1Exception safety guaranteesY 
                              6.3.2Additions to header <functional> synopsisY 
                              6.3.3Class template hashY 
                              6.3.4Unordered associative container classesY 
                              6.3.4.1Header <unordered_set> synopsisY 
                              6.3.4.2Header <unordered_map> synopsisY 
                              6.3.4.3Class template unordered_setY 
                              6.3.4.3.1unordered_set constructorsY 
                              6.3.4.3.2unordered_set swapY 
                              6.3.4.4Class template unordered_mapY 
                              6.3.4.4.1unordered_map constructorsY 
                              6.3.4.4.2unordered_map element accessY 
                              6.3.4.4.3unordered_map swapY 
                              6.3.4.5Class template unordered_multisetY 
                              6.3.4.5.1unordered_multiset constructorsY 
                              6.3.4.5.2unordered_multiset swapY 
                              6.3.4.6Class template unordered_multimapY 
                              6.3.4.6.1unordered_multimap constructorsY 
                              6.3.4.6.2unordered_multimap swapY 
                              7Regular Expressions
                              7.1DefinitionsN 
                              7.2RequirementsN 
                              7.3Regular expressions summaryN 
                              7.4Header <regex> synopsisN 
                              7.5Namespace tr1::regex_constantsN 
                              7.5.1Bitmask Type syntax_option_typeN 
                              7.5.2Bitmask Type regex_constants::match_flag_typeN 
                              7.5.3Implementation defined error_typeN 
                              7.6Class regex_errorN 
                              7.7Class template regex_traitsN 
                              7.8Class template basic_regexN 
                              7.8.1basic_regex constantsN 
                              7.8.2basic_regex constructorsN 
                              7.8.3basic_regex assignN 
                              7.8.4basic_regex constant operationsN 
                              7.8.5basic_regex localeN 
                              7.8.6basic_regex swapN 
                              7.8.7basic_regex non-member functionsN 
                              7.8.7.1basic_regex non-member swapN 
                              7.9Class template sub_matchN 
                              7.9.1sub_match membersN 
                              7.9.2sub_match non-member operatorsN 
                              7.10Class template match_resultsN 
                              7.10.1match_results constructorsN 
                              7.10.2match_results sizeN 
                              7.10.3match_results element accessN 
                              7.10.4match_results formattingN 
                              7.10.5match_results allocatorN 
                              7.10.6match_results swapN 
                              7.11Regular expression algorithmsN 
                              7.11.1exceptionsN 
                              7.11.2regex_matchN 
                              7.11.3regex_searchN 
                              7.11.4regex_replaceN 
                              7.12Regular expression IteratorsN 
                              7.12.1Class template regex_iteratorN 
                              7.12.1.1regex_iterator constructorsN 
                              7.12.1.2regex_iterator comparisonsN 
                              7.12.1.3regex_iterator dereferenceN 
                              7.12.1.4regex_iterator incrementN 
                              7.12.2Class template regex_token_iteratorN 
                              7.12.2.1regex_token_iterator constructorsN 
                              7.12.2.2regex_token_iterator comparisonsN 
                              7.12.2.3regex_token_iterator dereferenceN 
                              7.12.2.4regex_token_iterator incrementN 
                              7.13Modified ECMAScript regular expression grammarN 
                              8C Compatibility
                              8.1Additions to header <complex>Y 
                              8.1.1SynopsisY 
                              8.1.2Function acosY 
                              8.1.3Function asinY 
                              8.1.4Function atanY 
                              8.1.5Function acoshY 
                              8.1.6Function asinhY 
                              8.1.7Function atanhY 
                              8.1.8Function fabsY 
                              8.1.9Additional OverloadsY 
                              8.2Header <ccomplex>NDR 551
                              8.3Header <complex.h>NDR 551
                              8.4Additions to header <cctype>Y 
                              8.4.1SynopsisY 
                              8.4.2Function isblankY 
                              8.5Additions to header <ctype.h>Y 
                              8.6Header <cfenv>Y 
                              8.6.1SynopsisY 
                              8.6.2DefinitionsY 
                              8.7Header <fenv.h>Y 
                              8.8Additions to header <cfloat>Y 
                              8.9Additions to header <float.h>Y 
                              8.10Additions to header <ios>N 
                              8.10.1SynopsisN 
                              8.10.2Function hexfloatN 
                              8.11Header <cinttypes>Y 
                              8.11.1SynopsisYDR 557
                              8.11.2DefinitionsY 
                              8.12Header <inttypes.h>Y 
                              8.13Additions to header <climits>Y 
                              8.14Additions to header <limits.h>Y 
                              8.15Additions to header <locale>N 
                              8.16Additions to header <cmath>Y 
                              8.16.1SynopsisY 
                              8.16.2DefinitionsY 
                              8.16.3Function template definitionsY 
                              8.16.4Additional overloadsYDR 568; DR 550
                              8.17Additions to header <math.h>Y 
                              8.18Additions to header <cstdarg>Y 
                              8.19Additions to header <stdarg.h>Y 
                              8.20The header <cstdbool>Y 
                              8.21The header <stdbool.h>Y 
                              8.22The header <cstdint>Y 
                              8.22.1SynopsisY 
                              8.22.2DefinitionsY 
                              8.23The header <stdint.h>Y 
                              8.24Additions to header <cstdio>Y 
                              8.24.1SynopsisY 
                              8.24.2DefinitionsY 
                              8.24.3Additional format specifiersYC library dependency
                              8.24.4Additions to header <stdio.h>Y 
                              8.25Additions to header <cstdlib>Y 
                              8.25.1SynopsisY 
                              8.25.2DefinitionsY 
                              8.25.3Function absY 
                              8.25.4Function divY 
                              8.26Additions to header <stdlib.h>Y 
                              8.27Header <ctgmath>YDR 551
                              8.28Header <tgmath.h>YDR 551
                              8.29Additions to header <ctime>YC library dependency
                              8.30Additions to header <cwchar>Y 
                              8.30.1SynopsisY 
                              8.30.2DefinitionsY 
                              8.30.3Additional wide format specifiersYC library dependency
                              8.31Additions to header <wchar.h>Y 
                              8.32Additions to header <cwctype>Y 
                              8.32.1SynopsisY 
                              8.32.2Function iswblankY 
                              8.33Additions to header <wctype.h>Y 

                              C++ TR 24733
                              
 This table is based on the table of contents of
 ISO/IEC TR 24733 Date: 2009-08-28
 Extension for the programming language C++ to support
@@ -240,7 +240,7 @@ decimal floating-point arithmetic
 
                              
 This page describes the TR 24733 support in mainline GCC SVN, not in any
 particular release.
-
                              Table 1.4. C++ TR 24733 Implementation Status
                              SectionDescriptionStatusComments
                              
+
                              Table 1.4. C++ TR 24733 Implementation Status
                              SectionDescriptionStatusComments
                              
 	0
       
 	Introduction
diff --git a/libstdc++-v3/doc/html/manual/streambufs.html b/libstdc++-v3/doc/html/manual/streambufs.html
index c8fc68abf2d..388e5721275 100644
--- a/libstdc++-v3/doc/html/manual/streambufs.html
+++ b/libstdc++-v3/doc/html/manual/streambufs.html
@@ -1,9 +1,9 @@
 
 
-Chapter 25. Stream Buffers
                              Chapter 25. Stream Buffers
                              Prev Part XI. 
+Chapter 25. Stream Buffers
                              Chapter 25. Stream Buffers
                              Prev Part XI. 
   Input and Output
   
- Next
                              Chapter 25. Stream Buffers
                              Table of Contents
                              Derived streambuf Classes
                              Buffering
                              Derived streambuf Classes
                              
+
                              		 Next
                              Chapter 25. Stream Buffers
                              Table of Contents
                              Derived streambuf Classes
                              Buffering
                              Derived streambuf Classes
                              
     
                              Creating your own stream buffers for I/O can be remarkably easy.
       If you are interested in doing so, we highly recommend two very
       excellent books:
diff --git a/libstdc++-v3/doc/html/manual/strings.html b/libstdc++-v3/doc/html/manual/strings.html
index a1e78f27289..7f377095f25 100644
--- a/libstdc++-v3/doc/html/manual/strings.html
+++ b/libstdc++-v3/doc/html/manual/strings.html
@@ -1,9 +1,9 @@
 
 
-Part V.  Strings
                              Part V. 
+Part V.  Strings
                              Part V. 
   Strings
   
-
                              Prev The GNU C++ Library Next
                              Part V. 
+
                              Prev The GNU C++ Library Next
                              Part V. 
   Strings
-  
+  
 
                              Table of Contents
                              13. String Classes
                              Simple Transformations
                              Case Sensitivity
                              Arbitrary Character Types
                              Tokenizing
                              Shrink to Fit
                              CString (MFC)
                              Prev Up Next
                              shared_ptr Home Chapter 13. String Classes
                              
diff --git a/libstdc++-v3/doc/html/manual/stringstreams.html b/libstdc++-v3/doc/html/manual/stringstreams.html
index ff21ecd1cce..718965570e4 100644
--- a/libstdc++-v3/doc/html/manual/stringstreams.html
+++ b/libstdc++-v3/doc/html/manual/stringstreams.html
@@ -1,9 +1,9 @@
 
 
-Chapter 26. Memory Based Streams
                              Chapter 26. Memory Based Streams
                              Prev Part XI. 
+Chapter 26. Memory Based Streams
                              Chapter 26. Memory Based Streams
                              Prev Part XI. 
   Input and Output
   
- Next
                              Chapter 26. Memory Based Streams
                              Table of Contents
                              Compatibility With strstream
                              Compatibility With strstream
                              
+
                              		 Next
                              Chapter 26. Memory Based Streams
                              Table of Contents
                              Compatibility With strstream
                              Compatibility With strstream
                              
     
                              Stringstreams (defined in the header <sstream>)
       are in this author's opinion one of the coolest things since
       sliced time.  An example of their use is in the Received Wisdom
diff --git a/libstdc++-v3/doc/html/manual/support.html b/libstdc++-v3/doc/html/manual/support.html
index fb217b89a0d..588cb219b7d 100644
--- a/libstdc++-v3/doc/html/manual/support.html
+++ b/libstdc++-v3/doc/html/manual/support.html
@@ -1,9 +1,9 @@
 
 
-Part II.  Support
                              Part II. 
+Part II.  Support
                              Part II. 
   Support
   
-
                              Prev The GNU C++ Library Next
                              Part II. 
+
                              Prev The GNU C++ Library Next
                              Part II. 
   Support
-  
+  
 
                              Table of Contents
                              4. Types
                              Fundamental Types
                              Numeric Properties
                              NULL
                              5. Dynamic Memory
                              6. Termination
                              Termination Handlers
                              Verbose Terminate Handler
                              Prev Up Next
                              Debugging Support Home 
                              
diff --git a/libstdc++-v3/doc/html/manual/termination.html b/libstdc++-v3/doc/html/manual/termination.html
index bf3b74ca515..ff86016f613 100644
--- a/libstdc++-v3/doc/html/manual/termination.html
+++ b/libstdc++-v3/doc/html/manual/termination.html
@@ -1,9 +1,9 @@
 
 
-Chapter 6. Termination
                              Chapter 6. Termination
                              Prev Part II. 
+Chapter 6. Termination
                              Chapter 6. Termination
                              Prev Part II. 
   Support
   
- Next
                              Chapter 6. Termination
                              Table of Contents
                              Termination Handlers
                              Verbose Terminate Handler
                              Termination Handlers
                              
+
                              		 Next
                              Chapter 6. Termination
                              Table of Contents
                              Termination Handlers
                              Verbose Terminate Handler
                              Termination Handlers
                              
       Not many changes here to cstdlib.  You should note that the
       abort() function does not call the
       destructors of automatic nor static objects, so if you're
@@ -15,14 +15,14 @@
       The good old exit() function can be a bit
       funky, too, until you look closer.  Basically, three points to
       remember are:
-    
                              1. 
+    
                                1. 
 	Static objects are destroyed in reverse order of their creation.
-	
                                2. 
+	
                                3. 
 	Functions registered with atexit() are called in
         reverse order of registration, once per registration call.
         (This isn't actually new.)
-	
                                4. 
-	The previous two actions are “interleaved,” that is,
+	
                                5. 
+	The previous two actions are “interleaved,” that is,
         given this pseudocode:
 	
                                     extern "C or C++" void  f1 (void);
diff --git a/libstdc++-v3/doc/html/manual/test.html b/libstdc++-v3/doc/html/manual/test.html
index 80988a4febe..ce8fa2a942d 100644
--- a/libstdc++-v3/doc/html/manual/test.html
+++ b/libstdc++-v3/doc/html/manual/test.html
@@ -1,18 +1,18 @@
 
 
-Test
                                  Test
                                  Prev Appendix B. 
+Test
                                  Test
                                  Prev Appendix B. 
   Porting and Maintenance
   
- Next
                                  Test
                                  
+
                                  		 Next
                                  Test
                                  
 The libstdc++ testsuite includes testing for standard conformance,
 regressions, ABI, and performance.
-
                                  Organization
                                  Directory Layout
                                  
+
                                  Organization
                                  Directory Layout
                                  
   The directory libsrcdir/testsuite contains the
   individual test cases organized in sub-directories corresponding to
   chapters of the C++ standard (detailed below), the dejagnu test
   harness support files, and sources to various testsuite utilities
   that are packaged in a separate testing library.
-
                                   
+
                                  
   All test cases for functionality required by the runtime components
   of the C++ standard (ISO 14882) are files within the following
   directories.
@@ -27,6 +27,9 @@ regressions, ABI, and performance.
 25_algorithms
 26_numerics
 27_io
+28_regex
+29_atomics
+30_threads
    
                                  
       In addition, the following directories include test files:
    
                                  @@ -35,7 +38,6 @@ backward	  Tests for backwards compatibility and deprecated features.
 demangle	  Tests for __cxa_demangle, the IA 64 C++ ABI demangler
 ext		  Tests for extensions.
 performance	  Tests for performance analysis, and performance regressions.
-thread		  Tests for threads.
    
                                  
       Some directories don't have test files, but instead contain
       auxiliary information:
@@ -74,38 +76,38 @@ util		  Files for libtestc++, utilities and testing routines.
 21_strings/basic_string/find/wchar_t/3.cc
    
                                  
       All new tests should be written with the policy of one test
-      case, one file in mind. 
-   
                                Naming Conventions
                                
+      case, one file in mind.
+   
                                Naming Conventions
                                
       In addition, there are some special names and suffixes that are
       used within the testsuite to designate particular kinds of
       tests.
-   
                                • 
+   
                                  • 
    _xin.cc
   
                                    
       This test case expects some kind of interactive input in order
       to finish or pass. At the moment, the interactive tests are not
       run by default. Instead, they are run by hand, like:
-   
                                     
+   
                                     g++ 27_io/objects/char/3_xin.cc
 cat 27_io/objects/char/3_xin.in | a.out
-     
                                  • 
+     
                                  • 
      .in
    
                                    
       This file contains the expected input for the corresponding 
       _xin.cc test case.
-   
                                  • 
+   
                                  • 
    _neg.cc
   
                                    
       This test case is expected to fail: it's a negative test. At the
       moment, these are almost always compile time errors.
-   
                                  • 
+   
                                  • 
    char
   
                                    
       This can either be a directory name or part of a longer file
       name, and indicates that this file, or the files within this
       directory are testing the char instantiation of a
       template.
-   
                                  • 
+   
                                  • 
    wchar_t
   
                                    
       This can either be a directory name or part of a longer file
@@ -114,14 +116,14 @@ cat 27_io/objects/char/3_xin.in | a.out
       a template. Some hosts do not support wchar_t
       functionality, so for these targets, all of these tests will not
       be run.
-   
                                  • 
+   
                                  • 
    thread
   
                                    
       This can either be a directory name or part of a longer file
       name, and indicates that this file, or the files within this
       directory are testing situations where multiple threads are
       being used.
-   
                                  • 
+   
                                  • 
    performance
   
                                    
       This can either be an enclosing directory name or part of a
@@ -129,7 +131,7 @@ cat 27_io/objects/char/3_xin.in | a.out
       analyze runtime performance, for performance regression testing,
       or for other optimization related analysis. At the moment, these
       test cases are not run by default.
-   
                                Running the Testsuite
                                Basic
                                
+   
                              Running the Testsuite
                              Basic
                              
       You can check the status of the build without installing it
       using the dejagnu harness, much like the rest of the gcc
       tools.
                               make check
                              in the libbuilddir directory.
                              or
                               make check-target-libstdc++-v3
                              in the gccbuilddir directory.
@@ -149,7 +151,7 @@ cat 27_io/objects/char/3_xin.in | a.out
        archived on a daily basis on the gcc-testresults
        mailing list. Please check either of these places for a similar
        combination of source version, operating system, and host CPU.
-     
                              Variations
                              
+     
                              Variations
                              
       There are several options for running tests, including testing
       the regression tests, testing a subset of the regression tests,
       testing the performance tests, testing just compilation, testing
@@ -185,7 +187,7 @@ make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=calmrisc32-sid"
 
 --target=xscale-elf (newlib/sim)
 make check-target-libstdc++-v3 RUNTESTFLAGS="--target_board=arm-sim"
-
                               
+
                              
       Also, here is an example of how to run the libstdc++ testsuite
       for a multilibed build directory with different ABI settings:
     
                              @@ -207,7 +209,7 @@ runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
       same name as files created by other testsuites (like the ones
       for GCC and G++), so you should not try to run all the
       testsuites in parallel from the same directory.
-    
                               
+    
                              
       In addition, there are some testing options that are mostly of
       interest to library maintainers and system integrators. As such,
       these tests may not work on all cpu and host combinations, and
@@ -220,32 +222,32 @@ runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
    
                              
     Five files are generated that determine what test files
     are run. These files are:
-  
                              • 
+  
                                • 
 	 testsuite_files
-       
                                   
+       
                                  
 	 This is a list of all the test cases that will be run. Each
 	 test case is on a separate line, given with an absolute path
 	 from the libsrcdir/testsuite directory.
-       
                                • 
+       
                                • 
 	 testsuite_files_interactive
-       
                                   
+       
                                  
 	 This is a list of all the interactive test cases, using the
 	 same format as the file list above. These tests are not run
 	 by default.
-     
                                • 
+     
                                • 
 	 testsuite_files_performance
-       
                                   
+       
                                  
 	 This is a list of all the performance test cases, using the
 	 same format as the file list above. These tests are not run
 	 by default.
-     
                                • 
+     
                                • 
 	 testsuite_thread
-       
                                   
+       
                                  
 	 This file indicates that the host system can run tests which
 	 involved multiple threads.
-       
                                • 
+       
                                • 
 	 testsuite_wchar_t
-       
                                   
+       
                                  
 	 This file indicates that the host system can run the wchar_t
 	 tests, and corresponds to the macro definition 
 	 _GLIBCXX_USE_WCHAR_T in the file c++config.h.
@@ -254,7 +256,7 @@ runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
    
                                  
      The library ABI can be tested. This involves testing the shared
      library against an ABI-defining previous version of symbol
-     exports. 
+     exports.
    
                                      make check-compile
   
                                  
@@ -275,7 +277,7 @@ runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
       We are interested in any strange failures of the testsuite;
       please email the main libstdc++ mailing list if you see
       something odd or have questions.
-   
                                Permutations
                                
+   
                                Permutations
                                
       To run the libstdc++ test suite under the debug mode, edit
       libstdc++-v3/scripts/testsuite_flags to add the
       compile-time flag -D_GLIBCXX_DEBUG to the
@@ -295,10 +297,10 @@ runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite
       Or, just run the testsuites with CXXFLAGS
       set to -D_GLIBCXX_DEBUG or
       -D_GLIBCXX_PARALLEL.
-    
                              Writing a new test case
                              
+    
                              Writing a new test case
                              
     The first step in making a new test case is to choose the correct
     directory and file name, given the organization as previously
-    described. 
+    described.
    
                              
     All files are copyright the FSF, and GPL'd: this is very
     important.  The first copyright year should correspond to the date
@@ -406,7 +408,7 @@ up in the normal.exp file.
 // { dg-options "-O0" { target *-*-* } }
 
                              
     More examples can be found in the libstdc++-v3/testsuite/*/*.cc files.
-   
                              Test Harness and Utilities
                              Dejagnu Harness Details
                               
+   
                              Test Harness and Utilities
                              Dejagnu Harness Details
                              
     Underlying details of testing for conformance and regressions are
     abstracted via the GNU Dejagnu package. This is similar to the
     rest of GCC.
@@ -433,7 +435,7 @@ callbacks loaded from the support library.
 
                              The config directory is searched for any particular "target
 board" information unique to this library.  This is currently unused and sets
 only default variables.
-
                              Utilities
                               
+
                              Utilities
                              
   
                              
    The testsuite directory also contains some files that implement
    functionality that is intended to make writing test cases easier,
@@ -445,48 +447,188 @@ only default variables.
    during testing.
   
                              
   These files include the following functionality:
-  
                              • 
+  
                                • 
        testsuite_abi.h,
        testsuite_abi.cc,
        testsuite_abi_check.cc
        
                                  
-        Creates the executable abi_check.
-        Used to check correctness of symbol versioning, visibility of
-        exported symbols, and compatibility on symbols in the shared
-        library, for hosts that support this feature. More information
-        can be found in the ABI documentation here
-       
                                • 
+	Creates the executable abi_check.
+	Used to check correctness of symbol versioning, visibility of
+	exported symbols, and compatibility on symbols in the shared
+	library, for hosts that support this feature. More information
+	can be found in the ABI documentation here
+       
                                • 
        testsuite_allocator.h,
        testsuite_allocator.cc
        
                                  
-        Contains specialized allocators that keep track of construction
-        and destruction. Also, support for overriding global new and
-        delete operators, including verification that new and delete
-        are called during execution, and that allocation over max_size
-        fails.
-       
                                • 
+	Contains specialized allocators that keep track of construction
+	and destruction. Also, support for overriding global new and
+	delete operators, including verification that new and delete
+	are called during execution, and that allocation over max_size
+	fails.
+       
                                • 
        testsuite_character.h
        
                                  
-        Contains std::char_traits and
-        std::codecvt specializations for a user-defined
-        POD.
-       
                                • 
+	Contains std::char_traits and
+	std::codecvt specializations for a user-defined
+	POD.
+       
                                • 
        testsuite_hooks.h,
        testsuite_hooks.cc
        
                                  
        A large number of utilities, including:
-       
                                  • VERIFY
                                  • set_memory_limits
                                  • verify_demangle
                                  • run_tests_wrapped_locale
                                  • run_tests_wrapped_env
                                  • try_named_locale
                                  • try_mkfifo
                                  • func_callback
                                  • counter
                                  • copy_tracker
                                  • copy_constructor
                                  • assignment_operator
                                  • destructor
                                  • pod_char, pod_int and associated char_traits specializations
                                • 
+       
                                  • VERIFY
                                  • set_memory_limits
                                  • verify_demangle
                                  • run_tests_wrapped_locale
                                  • run_tests_wrapped_env
                                  • try_named_locale
                                  • try_mkfifo
                                  • func_callback
                                  • counter
                                  • copy_tracker
                                  • copy_constructor
                                  • assignment_operator
                                  • destructor
                                  • pod_char, pod_int and associated char_traits specializations
                                • 
 	 testsuite_io.h
        
                                  
        Error, exception, and constraint checking for
        std::streambuf, std::basic_stringbuf, std::basic_filebuf.
-       
                                • 
+       
                                • 
 	 testsuite_iterators.h
        
                                  
 	 Wrappers for various iterators.
-       
                                • 
+       
                                • 
 	 testsuite_performance.h
        
                                  
        A number of class abstractions for performance counters, and
        reporting functions including:
-       
                                  • time_counter
                                  • resource_counter
                                  • report_performance
                              Prev Up Next
                              Porting to New Hardware or Operating Systems Home ABI Policy and Guidelines
                              
+       
                              • time_counter
                              • resource_counter
                              • report_performance
                              Special Topics
                              
+  Qualifying Exception Safety Guarantees
+  
+
                              Overview
                              
+	 Testing is composed of running a particular test sequence,
+	 and looking at what happens to the surrounding code when
+	 exceptions are thrown. Each test is composed of measuring
+	 initial state, executing a particular sequence of code under
+	 some instrumented conditions, measuring a final state, and
+	 then examining the differences between the two states.
+       
                              
+	 Test sequences are composed of constructed code sequences
+	 that exercise a particular function or member function, and
+	 either confirm no exceptions were generated, or confirm the
+	 consistency/coherency of the test subject in the event of a
+	 thrown exception.
+       
                              
+	 Random code paths can be constructed using the the basic test
+	 sequences and instrumentation as above, only combined in a
+	 random or pseudo-random way.
+       
                               To compute the code paths that throw, test instruments
+	 are used that throw on allocation events
+	 (__gnu_cxx::throw_allocator_random
+	 and __gnu_cxx::throw_allocator_limit)
+	 and copy, assignment, comparison, increment, swap, and
+	 various operators
+	 (__gnu_cxx::throw_type_random
+	 and __gnu_cxx::throw_type_limit). Looping
+	 through a given test sequence and conditionally throwing in
+	 all instrumented places.  Then, when the test sequence
+	 completes without an exception being thrown, assume all
+	 potential error paths have been exercised in a sequential
+	 manner.
+       
                              
+    Existing tests
+
                              • 
+	 Ad Hoc
+       
                                
+	 For example,
+	 testsuite/23_containers/list/modifiers/3.cc.
+       
                              • 
+	 Policy Based Data Structures
+       
                                
+	 For example, take the test
+	 functor rand_reg_test in
+	 in testsuite/ext/pb_ds/regression/tree_no_data_map_rand.cc. This uses container_rand_regression_test in
+testsuite/util/regression/rand/assoc/container_rand_regression_test.h.
+
+       
                                
+	 Which has several tests for container member functions,
+Includes control and test container objects. Configuration includes
+random seed, iterations, number of distinct values, and the
+probability that and exception will be thrown. Assumes instantiating
+container uses an extension
+allocator, __gnu_cxx::throw_allocator_random,
+as the allocator type.
+       
                              • 
+	 C++0x Container Requirements.
+       
                                
+	 Coverage is currently limited to testing container
+	 requirements for exception safety,
+	 although __gnu_cxx::throw_type meets
+	 the additional type requirements for testing numeric data
+	 structures and instantiating algorithms.
+       
                                
+	 Of particular interest is extending testing to algorithms and
+	 then to parallel algorithms. Also io, and locales.
+       
                              
+C++0x Requirements Test Sequence Descriptions
+
                              • 
+	 Basic
+       
                                
+	 Basic consistency on exception propagation tests. For
+	 each container, an object of that container is constructed,
+	 a specific member function is exercised in
+	 a try block, and then any thrown
+	 exceptions lead to error checking in the appropriate
+	 catch block. The container's use of
+	 resources is compared to the container's use prior to the
+	 test block. Resource monitoring is limited to allocations
+	 made through the container's allocator_type,
+	 which should be sufficient for container data
+	 structures. Included in these tests are member functions
+	 are iterator and const_iterator
+	 operations, pop_front, pop_back, push_front, push_back, insert, erase, swap, clear,
+	 and rehash. The container in question is
+	 instantiated with two instrumented template arguments,
+	 with __gnu_cxx::throw_allocator_limit
+	 as the allocator type, and
+	 with __gnu_cxx::throw_type_limit as
+	 the value type. This allows the test to loop through
+	 conditional throw points.
+       
                                
+	 The general form is demonstrated in
+	 testsuite/23_containers/list/requirements/exception/basic.cc
+	 . The instantiating test object is __gnu_test::basic_safety and is detailed in testsuite/util/exception/safety.h.
+       
                              • 
+	 Generation Prohibited
+       
                                
+	 Exception generation tests. For each container, an object of
+	 that container is constructed and all member functions
+	 required to not throw exceptions are exercised. Included in
+	 these tests are member functions
+	 are iterator and const_iterator operations, erase, pop_front, pop_back, swap,
+	 and clear. The container in question is
+	 instantiated with two instrumented template arguments,
+	 with __gnu_cxx::throw_allocator_random
+	 as the allocator type, and
+	 with __gnu_cxx::throw_type_random as
+	 the value type. This test does not loop, an instead is sudden
+	 death: first error fails.
+       
                                
+	 The general form is demonstrated in
+	 testsuite/23_containers/list/requirements/exception/generation_prohibited.cc
+	 . The instantiating test object is __gnu_test::generation_prohibited and is detailed in testsuite/util/exception/safety.h.
+       
                              • 
+	 Propagation Consistent
+       
                                
+	 Container rollback on exception propagation tests. For
+	 each container, an object of that container is constructed,
+	 a specific member function that requires rollback to a previous
+	 known good state is exercised in
+	 a try block, and then any thrown
+	 exceptions lead to error checking in the appropriate
+	 catch block. The container is compared to
+	 the container's last known good state using such parameters
+	 as size, contents, and iterator references. Included in these
+	 tests are member functions
+	 are push_front, push_back, insert,
+	 and rehash. The container in question is
+	 instantiated with two instrumented template arguments,
+	 with __gnu_cxx::throw_allocator_limit
+	 as the allocator type, and
+	 with __gnu_cxx::throw_type_limit as
+	 the value type. This allows the test to loop through
+	 conditional throw points.
+       
                                
+	 The general form demonstrated in
+	 testsuite/23_containers/list/requirements/exception/propagation_coherent.cc
+	 . The instantiating test object is __gnu_test::propagation_coherent and is detailed in testsuite/util/exception/safety.h.
+       
                              Prev Up Next
                              Porting to New Hardware or Operating Systems Home ABI Policy and Guidelines
                              
diff --git a/libstdc++-v3/doc/html/manual/traits.html b/libstdc++-v3/doc/html/manual/traits.html
index ee5e9d423ae..1d1e6fb75bf 100644
--- a/libstdc++-v3/doc/html/manual/traits.html
+++ b/libstdc++-v3/doc/html/manual/traits.html
@@ -1,9 +1,9 @@
 
 
-Chapter 12. Traits
                              Chapter 12. Traits
                              Prev Part IV. 
+Chapter 12. Traits
                              Chapter 12. Traits
                              Prev Part IV. 
   Utilities
   
- Next
                              Chapter 12. Traits
                              
+
                              		 Next
                              Chapter 12. Traits
                              
   
                              Prev Up Next
                              shared_ptr Home Part V. 
   Strings
   
diff --git a/libstdc++-v3/doc/html/manual/using.html b/libstdc++-v3/doc/html/manual/using.html
index 1d63cb53087..e84ce3a1ba1 100644
--- a/libstdc++-v3/doc/html/manual/using.html
+++ b/libstdc++-v3/doc/html/manual/using.html
@@ -1,9 +1,9 @@
 
 
-Chapter 3. Using
                              Chapter 3. Using
                              Prev Part I. 
+Chapter 3. Using
                              Chapter 3. Using
                              Prev Part I. 
   Introduction
   
- Next
                              Chapter 3. Using
                              Table of Contents
                              Linking Library Binary Files
                              Headers
                              Header Files
                              Mixing Headers
                              The C Headers and namespace std
                              Precompiled Headers
                              Namespaces
                              Available Namespaces
                              namespace std
                              Using Namespace Composition
                              Macros
                              Concurrency
                              Prerequisites
                              Thread Safety
                              Atomics
                              IO
                              Containers
                              Exceptions
                              Exception Safety
                              Exception Neutrality
                              Doing without
                              Compatibility
                              Debugging Support
                              Using g++
                              Debug Versions of Library Binary Files
                              Memory Leak Hunting
                              Using gdb
                              Tracking uncaught exceptions
                              Debug Mode
                              Compile Time Checking
                              Profile-based Performance Analysis
                              Linking Library Binary Files
                              
+
                              		 Next
                              Chapter 3. Using
                              Table of Contents
                              Linking Library Binary Files
                              Headers
                              Header Files
                              Mixing Headers
                              The C Headers and namespace std
                              Precompiled Headers
                              Namespaces
                              Available Namespaces
                              namespace std
                              Using Namespace Composition
                              Macros
                              Concurrency
                              Prerequisites
                              Thread Safety
                              Atomics
                              IO
                              Containers
                              Exceptions
                              Exception Safety
                              Exception Neutrality
                              Doing without
                              Compatibility
                              Debugging Support
                              Using g++
                              Debug Versions of Library Binary Files
                              Memory Leak Hunting
                              Using gdb
                              Tracking uncaught exceptions
                              Debug Mode
                              Compile Time Checking
                              Profile-based Performance Analysis
                              Linking Library Binary Files
                              
       If you only built a static library (libstdc++.a), or if you
       specified static linking, you don't have to worry about this.
       But if you built a shared library (libstdc++.so) and linked
@@ -13,26 +13,26 @@
       Methods vary for different platforms and different styles, but
       the usual ones are printed to the screen during installation.
       They include:
-    
                              • 
+    
                                • 
 	  At runtime set LD_LIBRARY_PATH in your environment
 	  correctly, so that the shared library for libstdc++ can be
 	  found and loaded.  Be certain that you understand all of the
 	  other implications and behavior of LD_LIBRARY_PATH first
 	  (few people do, and they get into trouble).
-	
                                • 
+	
                                • 
 	  Compile the path to find the library at runtime into the
 	  program.  This can be done by passing certain options to
 	  g++, which will in turn pass them on to the linker.  The
 	  exact format of the options is dependent on which linker you
 	  use:
-	
                                  • 
+	
                                    • 
 	      GNU ld (default on Linux):-Wl,--rpath,destdir/lib
-	    
                                    • 
+	    
                                    • 
 	      IRIX ld:
 	      -Wl,-rpath,destdir/lib
-	    
                                    • 
+	    
                                    • 
 	  Solaris ld:-Wl,-Rdestdir/lib
-	  
                                    • 
+	  
                                    • 
 	      More...?  Let us know!
 	    
                                  
       Use the ldd utility to show which library the
diff --git a/libstdc++-v3/doc/html/manual/using_concurrency.html b/libstdc++-v3/doc/html/manual/using_concurrency.html
index 45a0e7d784d..74b92b5b6c3 100644
--- a/libstdc++-v3/doc/html/manual/using_concurrency.html
+++ b/libstdc++-v3/doc/html/manual/using_concurrency.html
@@ -1,10 +1,10 @@
 
 
-Concurrency
                                  Concurrency
                                  Prev Chapter 3. Using Next
                                  Concurrency
                                  This section discusses issues surrounding the proper compilation
+Concurrency
                                  Concurrency
                                  Prev Chapter 3. Using Next
                                  Concurrency
                                  This section discusses issues surrounding the proper compilation
       of multithreaded applications which use the Standard C++
       library.  This information is GCC-specific since the C++
       standard does not address matters of multithreaded applications.
-   
                                  Prerequisites
                                  All normal disclaimers aside, multithreaded C++ application are
+   
                                  Prerequisites
                                  All normal disclaimers aside, multithreaded C++ application are
       only supported when libstdc++ and all user code was built with
       compilers which report (via  gcc/g++ -v ) the same thread
       model and that model is not single.  As long as your
@@ -33,12 +33,12 @@
       -pthread is honored.  Some other ports use other switches.
       AFAIK, none of this is properly documented anywhere other than
       in ``gcc -dumpspecs'' (look at lib and cpp entries).
-   
                                  Thread Safety
                                  
+   
                                  Thread Safety
                                  
 We currently use the SGI STL definition of thread safety.
 
                                  The library strives to be thread-safe when all of the following
          conditions are met:
-      
                                  • The system's libc is itself thread-safe,
-       
                                  • 
+      
                                    • The system's libc is itself thread-safe,
+       
                                    • 
 	   The compiler in use reports a thread model other than
 	   'single'. This can be tested via output from gcc
 	   -v. Multi-thread capable versions of gcc output
@@ -49,13 +49,13 @@ Using built-in specs.
 ...
 Thread model: posix
 gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
-
                                      Look for "Thread model" lines that aren't equal to "single."
                                    • 
+
                                      Look for "Thread model" lines that aren't equal to "single."
                                    • 
 	 Requisite command-line flags are used for atomic operations
 	 and threading. Examples of this include -pthread
 	 and -march=native, although specifics vary
 	 depending on the host environment. See Machine
 	 Dependent Options.
-       
                                    • 
+       
                                    • 
 	   An implementation of atomicity.h functions
            exists for the architecture in question. See the internals documentation for more details.
        
                                    The user-code must guard against concurrent method calls which may
@@ -89,9 +89,9 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
          this requirement includes both read and write access to objects;
          unless otherwise documented as safe, do not assume that two threads
          may access a shared standard library object at the same time.
-      
                                  Atomics
                                  
-    
                                  IO
                                  This gets a bit tricky.  Please read carefully, and bear with me.
-   
                                  Structure
                                  A wrapper
+      
                                  Atomics
                                  
+    
                                  IO
                                  This gets a bit tricky.  Please read carefully, and bear with me.
+   
                                  Structure
                                  A wrapper
       type called __basic_file provides our abstraction layer
       for the std::filebuf classes.  Nearly all decisions dealing
       with actual input and output must be made in __basic_file.
@@ -99,7 +99,7 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
       but is not used in the current code.  Providing locking at any higher
       level is akin to providing locking within containers, and is not done
       for the same reasons (see the links above).
-   
                                  Defaults
                                  The __basic_file type is simply a collection of small wrappers around
+   
                                  Defaults
                                  The __basic_file type is simply a collection of small wrappers around
       the C stdio layer (again, see the link under Structure).  We do no
       locking ourselves, but simply pass through to calls to fopen,
       fwrite, and so forth.
@@ -121,7 +121,7 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
       contained in the stream formatting classes (e.g., setting up callbacks
       inside an std::ofstream), you need to guard such accesses
       like any other critical shared resource.
-   
                                  Future
                                   A
+   
                                  Future
                                   A
       second choice may be available for I/O implementations:  libio.  This is
       disabled by default, and in fact will not currently work due to other
       issues.  It will be revisited, however.
@@ -146,10 +146,10 @@ gcc version 4.1.2 20070925 (Red Hat 4.1.2-33)
       version will see calls from libstdc++ directly into the glibc already
       installed.  For other platforms, a copy of the libio subsection will
       be built and included in libstdc++.
-   
                                  Alternatives
                                  Don't forget that other cstdio implementations are possible.  You could
+   
                                  Alternatives
                                  Don't forget that other cstdio implementations are possible.  You could
       easily write one to perform your own forms of locking, to solve your
       "interesting" problems.
-   
                                  Containers
                                  This section discusses issues surrounding the design of
+   
                                  Containers
                                  This section discusses issues surrounding the design of
       multithreaded applications which use Standard C++ containers.
       All information in this section is current as of the gcc 3.0
       release and all later point releases.  Although earlier gcc
diff --git a/libstdc++-v3/doc/html/manual/using_exceptions.html b/libstdc++-v3/doc/html/manual/using_exceptions.html
index 5c74e93ac8f..ccf7f7be4f7 100644
--- a/libstdc++-v3/doc/html/manual/using_exceptions.html
+++ b/libstdc++-v3/doc/html/manual/using_exceptions.html
@@ -1,6 +1,6 @@
 
 
-Exceptions
                                  Exceptions
                                  Prev Chapter 3. Using Next
                                  Exceptions
                                  
+Exceptions
                                  Exceptions
                                  Prev Chapter 3. Using Next
                                  Exceptions
                                  
 The C++ language provides language support for stack unwinding
 with try and catch blocks and
 the throw keyword.
@@ -12,7 +12,7 @@ exceptional circumstances.
 
                                  
 Two general topics of discussion follow:
 exception neutrality and exception safety.
-
                                  Exception Safety
                                   
+
                                  Exception Safety
                                   
     What is exception-safe code? 
   
                                  
     Will define this as reasonable and well-defined behavior by classes
@@ -27,7 +27,7 @@ exception neutrality and exception safety.
     Using the layered approach from Abrahams, can classify library
     components as providing set levels of safety. These will be called
     exception guarantees, and can be divided into three categories.
-  
                                  • 
+  
                                    • 
     One. Don't throw.
   
                                      
     As specified in 23.2.1 general container requirements. Applicable
@@ -36,14 +36,14 @@ exception neutrality and exception safety.
     Member
     functions erase, pop_back, pop_front, swap, clear. And iterator
     copy constructor and assignment operator.
-  
                                    • 
+  
                                    • 
     Two. Don't leak resources when exceptions are thrown. This is
-    also referred to as the “basic” exception safety guarantee.
+    also referred to as the “basic” exception safety guarantee.
   
                                      
     This applicable throughout the standard library.
-  
                                    • 
+  
                                    • 
     Three. Commit-or-rollback semantics.  This is
-    referred to as “strong” exception safety guarantee.
+    referred to as “strong” exception safety guarantee.
   
                                      
     As specified in 23.2.1 general container requirements. Applicable
     to container and string classes.
@@ -51,7 +51,7 @@ exception neutrality and exception safety.
     Member functions insert of a single
     element, push_back, push_front,
     and rehash.
-  
                                  Exception Neutrality
                                  
+  
                              Exception Neutrality
                              
     Simply put, once thrown an exception object should continue in
     flight unless handled explicitly. In practice, this means
     propagating exceptions should not be swallowed in
@@ -75,7 +75,7 @@ exception neutrality and exception safety.
     Unfortunately, this tends to be more of a guideline than a strict
     rule as applied to the standard library. As such, the following is
     a list of known problem areas where exceptions are not propagated.
-  
                              • 
+  
                                • 
       Input/Output
     
                                  
     The destructor ios_base::Init::~Init()
@@ -95,13 +95,13 @@ exception neutrality and exception safety.
     When closing the underlying
     file, basic_filebuf::close will swallow
     (non-cancellation) exceptions thrown and return NULL.
-  
                                • 
+  
                                • 
       Thread
     
                                  
       The constructors of thread that take a
       callable function argument swallow all exceptions resulting from
       executing the function argument.
-    
                              Doing without
                              
+    
                              Doing without
                              
     C++ is a language that strives to be as efficient as is possible
     in delivering features. As such, considerable care is used by both
     language implementer and designers to make sure unused features
@@ -220,7 +220,7 @@ exception neutrality and exception safety.
   substitution of the C language keyword
   const with the uglified
   doppelganger __const.
-
                              Compatibility
                              With C
                               
+
                              Compatibility
                              With C
                               
   C language code that is expecting to interoperate with C++ should be
   compiled with -fexceptions. This will make
   debugging a C language function called as part of C++-induced stack
@@ -235,7 +235,7 @@ is called.
   getting these details right. For GNU systems, all appropriate parts
   of the GNU C library are already compiled
   with -fexceptions.
-
                              With POSIX thread cancellation
                               
+
                              With POSIX thread cancellation
                               
   GNU systems re-use some of the exception handling mechanisms to
   track control flow for POSIX thread cancellation.
 
                              
@@ -266,7 +266,7 @@ is called.
   }
   catch(...)
   { this->_M_setstate(ios_base::badbit); }
-
                              Bibliography
                              
+
                              Bibliography
                              
       System Interface Definitions, Issue 7 (IEEE Std. 1003.1-2008)
     . 
       2.9.5 Thread Cancellation
@@ -274,44 +274,44 @@ is called.
       The Open Group/The Institute of Electrical and Electronics Engineers, Inc.. 
       
       
-    . 
                              
+    . 
                              
       Error and Exception Handling
     . David Abrahams . 
 	Boost
       . 
       
       
-    . 
                              
+    . 
                              
       Exception-Safety in Generic Components
     . David Abrahams. 
 	Boost
       . 
       
       
-    . 
                              
+    . 
                              
       Standard Library Exception Policy
     . Matt Austern. 
 	WG21 N1077
       . 
       
       
-    . 
                              
+    . 
                              
       ia64 c++ abi exception handling
     . Richard Henderson. 
 	GNU
       . 
       
       
-    . 
                              
+    . 
                              
       Appendix E: Standard-Library Exception Safety
     . Bjarne Stroustrup. 
       
       
-    . 
                              
+    . 
                              
       Exceptional C++
     . 
       Exception-Safety Issues and Techniques
-    . Herb Sutter. 
                              
+    . Herb Sutter. 
                              
       exception_defines.h #defines try/catch
     . 
       GCC Bug 25191
diff --git a/libstdc++-v3/doc/html/manual/using_headers.html b/libstdc++-v3/doc/html/manual/using_headers.html
index 4986fe585a3..04d86364403 100644
--- a/libstdc++-v3/doc/html/manual/using_headers.html
+++ b/libstdc++-v3/doc/html/manual/using_headers.html
@@ -1,6 +1,6 @@
 
 
-Headers
                              Headers
                              Prev Chapter 3. Using Next
                              Headers
                              Header Files
                              
+Headers
                              Headers
                              Prev Chapter 3. Using Next
                              Headers
                              Header Files
                              
      The C++ standard specifies the entire set of header files that
      must be available to all hosted implementations.  Actually, the
      word "files" is a misnomer, since the contents of the
@@ -20,19 +20,19 @@
      upcoming 200x standard.
    
                              
      C++98/03 include files. These are available in the default compilation mode, i.e. -std=c++98 or -std=gnu++98.
-   
                              Table 3.1. C++ 1998 Library Headers
                              algorithmbitsetcomplexdequeexception
                              fstreamfunctionaliomanipiosiosfwd
                              iostreamistreamiteratorlimitslist
                              localemapmemorynewnumeric
                              ostreamqueuesetsstreamstack
                              stdexceptstreambufstringutilitytypeinfo
                              valarrayvector   

                              Table 3.2. C++ 1998 Library Headers for C Library Facilities
                              cassertcerrnocctypecfloatciso646
                              climitsclocalecmathcsetjmpcsignal
                              cstdargcstddefcstdiocstdlibcstring
                              ctimecwcharcwctype  

                              
+   
                              Table 3.1. C++ 1998 Library Headers
                              algorithmbitsetcomplexdequeexception
                              fstreamfunctionaliomanipiosiosfwd
                              iostreamistreamiteratorlimitslist
                              localemapmemorynewnumeric
                              ostreamqueuesetsstreamstack
                              stdexceptstreambufstringutilitytypeinfo
                              valarrayvector   

                              Table 3.2. C++ 1998 Library Headers for C Library Facilities
                              cassertcerrnocctypecfloatciso646
                              climitsclocalecmathcsetjmpcsignal
                              cstdargcstddefcstdiocstdlibcstring
                              ctimecwcharcwctype  

                              
 C++0x include files. These are only available in C++0x compilation
 mode, i.e. -std=c++0x or -std=gnu++0x.
-
                              Table 3.3. C++ 200x Library Headers
                              algorithmarraybitsetchronocomplex
                              condition_variabledequeexceptionforward_listfstream
                              functionalfutureinitalizer_listiomanipios
                              iosfwdiostreamistreamiteratorlimits
                              listlocalemapmemorymutex
                              newnumericostreamqueuerandom
                              ratioregexsetsstreamstack
                              stdexceptstreambufstringsystem_errorthread
                              tupletype_traitstypeinfounordered_mapunordered_set
                              utilityvalarrayvector  

                              Table 3.4. C++ 200x Library Headers for C Library Facilities
                              cassertccomplexcctypecerrnocfenv
                              cfloatcinttypesciso646climitsclocale
                              cmathcsetjmpcsignalcstdargcstdatomic
                              cstdboolcstddefcstdintcstdlibcstdio
                              cstringctgmathctimecucharcwchar
                              cwctypestdatomic.h   

                              
+
                              Table 3.3. C++ 200x Library Headers
                              algorithmarraybitsetchronocomplex
                              condition_variabledequeexceptionforward_listfstream
                              functionalfutureinitalizer_listiomanipios
                              iosfwdiostreamistreamiteratorlimits
                              listlocalemapmemorymutex
                              newnumericostreamqueuerandom
                              ratioregexsetsstreamstack
                              stdexceptstreambufstringsystem_errorthread
                              tupletype_traitstypeinfounordered_mapunordered_set
                              utilityvalarrayvector  

                              Table 3.4. C++ 200x Library Headers for C Library Facilities
                              cassertccomplexcctypecerrnocfenv
                              cfloatcinttypesciso646climitsclocale
                              cmathcsetjmpcsignalcstdargcstdbool
                              cstddefcstdintcstdlibcstdiocstring
                              ctgmathctimecucharcwcharcwctype
                              stdatomic.h    

                              
   In addition, TR1 includes as:
-
                              Table 3.5. C++ TR 1 Library Headers
                              tr1/arraytr1/complextr1/memorytr1/functionaltr1/random
                              tr1/regextr1/tupletr1/type_traitstr1/unordered_maptr1/unordered_set
                              tr1/utility    

                              Table 3.6. C++ TR 1 Library Headers for C Library Facilities
                              tr1/ccomplextr1/cfenvtr1/cfloattr1/cmathtr1/cinttypes
                              tr1/climitstr1/cstdargtr1/cstdbooltr1/cstdinttr1/cstdio
                              tr1/cstdlibtr1/ctgmathtr1/ctimetr1/cwchartr1/cwctype

                              Decimal floating-point arithmetic is available if the C++
+
                              Table 3.5. C++ TR 1 Library Headers
                              tr1/arraytr1/complextr1/memorytr1/functionaltr1/random
                              tr1/regextr1/tupletr1/type_traitstr1/unordered_maptr1/unordered_set
                              tr1/utility    

                              Table 3.6. C++ TR 1 Library Headers for C Library Facilities
                              tr1/ccomplextr1/cfenvtr1/cfloattr1/cmathtr1/cinttypes
                              tr1/climitstr1/cstdargtr1/cstdbooltr1/cstdinttr1/cstdio
                              tr1/cstdlibtr1/ctgmathtr1/ctimetr1/cwchartr1/cwctype

                              Decimal floating-point arithmetic is available if the C++
 compiler supports scalar decimal floating-point types defined via
 __attribute__((mode(SD|DD|LD))).
-
                              Table 3.7. C++ TR 24733 Decimal Floating-Point Header
                              decimal/decimal

                              
+
                              Table 3.7. C++ TR 24733 Decimal Floating-Point Header
                              decimal/decimal

                              
   Also included are files for the C++ ABI interface:
-
                              Table 3.8. C++ ABI Headers
                              cxxabi.hcxxabi_forced.h

                              
+
                              Table 3.8. C++ ABI Headers
                              cxxabi.hcxxabi_forced.h

                              
   And a large variety of extensions.
-
                              Table 3.9. Extension Headers
                              ext/algorithmext/atomicity.hext/array_allocator.hext/bitmap_allocator.hext/cast.h
                              ext/codecvt_specializations.hext/concurrence.hext/debug_allocator.hext/enc_filebuf.hext/extptr_allocator.h
                              ext/functionalext/iteratorext/malloc_allocator.hext/memoryext/mt_allocator.h
                              ext/new_allocator.hext/numericext/numeric_traits.hext/pb_ds/assoc_container.hext/pb_ds/priority_queue.h
                              ext/pod_char_traits.hext/pool_allocator.hext/rb_treeext/ropeext/slist
                              ext/stdio_filebuf.hext/stdio_sync_filebuf.hext/throw_allocator.hext/typelist.hext/type_traits.h
                              ext/vstring.h    

                              Table 3.10. Extension Debug Headers
                              debug/bitsetdebug/dequedebug/listdebug/mapdebug/set
                              debug/stringdebug/unordered_mapdebug/unordered_setdebug/vector 

                              Table 3.11. Extension Profile Headers
                              profile/bitsetprofile/dequeprofile/listprofile/map
                              profile/setprofile/unordered_mapprofile/unordered_setprofile/vector

                              Table 3.12. Extension Parallel Headers
                              parallel/algorithmparallel/numeric

                              Mixing Headers
                               A few simple rules.
+
                              Table 3.9. Extension Headers
                              ext/algorithmext/atomicity.hext/array_allocator.hext/bitmap_allocator.hext/cast.h
                              ext/codecvt_specializations.hext/concurrence.hext/debug_allocator.hext/enc_filebuf.hext/extptr_allocator.h
                              ext/functionalext/iteratorext/malloc_allocator.hext/memoryext/mt_allocator.h
                              ext/new_allocator.hext/numericext/numeric_traits.hext/pb_ds/assoc_container.hext/pb_ds/priority_queue.h
                              ext/pod_char_traits.hext/pool_allocator.hext/rb_treeext/ropeext/slist
                              ext/stdio_filebuf.hext/stdio_sync_filebuf.hext/throw_allocator.hext/typelist.hext/type_traits.h
                              ext/vstring.h    

                              Table 3.10. Extension Debug Headers
                              debug/bitsetdebug/dequedebug/listdebug/mapdebug/set
                              debug/stringdebug/unordered_mapdebug/unordered_setdebug/vector 

                              Table 3.11. Extension Profile Headers
                              profile/bitsetprofile/dequeprofile/listprofile/map
                              profile/setprofile/unordered_mapprofile/unordered_setprofile/vector

                              Table 3.12. Extension Parallel Headers
                              parallel/algorithmparallel/numeric

                              Mixing Headers
                               A few simple rules.
 
                              First, mixing different dialects of the standard headers is not
 possible. It's an all-or-nothing affair. Thus, code like
 
                              @@ -55,7 +55,7 @@ same translation unit:
 #include <tr1/type_traits>
 #include <type_traits>
 
                               Several parts of C++0x diverge quite substantially from TR1 predecessors.
-
                              The C Headers and namespace std
                              
+
                              The C Headers and namespace std
                              
 	The standard specifies that if one includes the C-style header
 	(<math.h> in this case), the symbols will be available
 	in the global namespace and perhaps in
@@ -74,13 +74,13 @@ floating-point types. This means that std::sin can be
 used uniformly, instead of a combination
 of std::sinf, std::sin,
 and std::sinl.
-
                              Precompiled Headers
                              There are three base header files that are provided. They can be
+
                              Precompiled Headers
                              There are three base header files that are provided. They can be
 used to precompile the standard headers and extensions into binary
 files that may the be used to speed compiles that use these headers.
-
                              • stdc++.h
                                Includes all standard headers. Actual content varies depending on
+
                                • stdc++.h
                                  Includes all standard headers. Actual content varies depending on
 language dialect.
-
                                • stdtr1c++.h
                                  Includes all of <stdc++.h>, and adds all the TR1 headers.
-
                                • extc++.h
                                  Includes all of <stdtr1c++.h>, and adds all the Extension headers.
+
                                • stdtr1c++.h
                                  Includes all of <stdc++.h>, and adds all the TR1 headers.
+
                                • extc++.h
                                  Includes all of <stdtr1c++.h>, and adds all the Extension headers.
 
                                How to construct a .gch file from one of these base header files.
                                First, find the include directory for the compiler. One way to do
 this is:
                                 g++ -v hello.cc
diff --git a/libstdc++-v3/doc/html/manual/using_macros.html b/libstdc++-v3/doc/html/manual/using_macros.html
index 8067d35d462..b8c7eeed7f9 100644
--- a/libstdc++-v3/doc/html/manual/using_macros.html
+++ b/libstdc++-v3/doc/html/manual/using_macros.html
@@ -1,6 +1,6 @@
 
 
-Macros
                                Macros
                                Prev Chapter 3. Using Next
                                Macros
                                All pre-processor switches and configurations are all gathered
+Macros
                                Macros
                                Prev Chapter 3. Using Next
                                Macros
                                All pre-processor switches and configurations are all gathered
       in the file c++config.h, which is generated during
       the libstdc++ configuration and build process, and included by
       files part of the public libstdc++ API. Most of these macros
@@ -19,7 +19,7 @@
     document.
     
                                Below are the macros which users may change with #define/#undef or
       with -D/-U compiler flags.  The default state of the symbol is
-      listed.
                                “Configurable” (or “Not configurable”) means
+      listed.
                                “Configurable” (or “Not configurable”) means
       that the symbol is initially chosen (or not) based on
       --enable/--disable options at library build and configure time
       (documented here), with the
diff --git a/libstdc++-v3/doc/html/manual/using_namespaces.html b/libstdc++-v3/doc/html/manual/using_namespaces.html
index eb61a11bd55..c022dd5c890 100644
--- a/libstdc++-v3/doc/html/manual/using_namespaces.html
+++ b/libstdc++-v3/doc/html/manual/using_namespaces.html
@@ -1,31 +1,31 @@
 
 
-Namespaces
                                Namespaces
                                Prev Chapter 3. Using Next
                                Namespaces
                                Available Namespaces
                                 There are three main namespaces.
-
                                • std
                                  The ISO C++ standards specify that "all library entities are defined
+Namespaces
                                  Namespaces
                                  Prev Chapter 3. Using Next
                                  Namespaces
                                  Available Namespaces
                                   There are three main namespaces.
+
                                  • std
                                    The ISO C++ standards specify that "all library entities are defined
 within namespace std." This includes namespaces nested
 within namespace std, such as namespace
 std::tr1.
-
                                  • abi
                                    Specified by the C++ ABI. This ABI specifies a number of type and
+
                                  • abi
                                    Specified by the C++ ABI. This ABI specifies a number of type and
 function APIs supplemental to those required by the ISO C++ Standard,
 but necessary for interoperability.
-
                                  • __gnu_
                                    Indicating one of several GNU extensions. Choices
+
                                  • __gnu_
                                    Indicating one of several GNU extensions. Choices
 include __gnu_cxx, __gnu_debug, __gnu_parallel,
 and __gnu_pbds.
 
                                   A complete list of implementation namespaces (including namespace contents) is available in the generated source documentation. 
-
                                  namespace std
                                  
+
                                  namespace std
                                  
       One standard requirement is that the library components are defined
       in namespace std::. Thus, in order to use these types or
       functions, one must do one of two things:
-
                                  • put a kind of using-declaration in your source
+
                                    • put a kind of using-declaration in your source
 (either using namespace std; or i.e. using
 std::string;) This approach works well for individual source files, but
 should not be used in a global context, like header files.
-	  
                                    • use a fully
+	  
                                    • use a fully
 qualified namefor each library symbol
 (i.e. std::string, std::cout) Always can be
 used, and usually enhanced, by strategic use of typedefs. (In the
 cases where the qualified verbiage becomes unwieldy.)
-	  
                                  Using Namespace Composition
                                  
+	  
                                Using Namespace Composition
                                
 Best practice in programming suggests sequestering new data or
 functionality in a sanely-named, unique namespace whenever
 possible. This is considered an advantage over dumping everything in
diff --git a/libstdc++-v3/doc/html/manual/utilities.html b/libstdc++-v3/doc/html/manual/utilities.html
index 26cef8e6d18..2fa8ebde492 100644
--- a/libstdc++-v3/doc/html/manual/utilities.html
+++ b/libstdc++-v3/doc/html/manual/utilities.html
@@ -1,9 +1,9 @@
 
 
-Part IV.  Utilities
                                Part IV. 
+Part IV.  Utilities
                                Part IV. 
   Utilities
   
-
                                Prev The GNU C++ Library Next
                                Part IV. 
+
                                Prev The GNU C++ Library Next
                                Part IV. 
   Utilities
-  
+  
 
                                Table of Contents
                                9. Functors
                                10. Pairs
                                11. Memory
                                Allocators
                                Requirements
                                Design Issues
                                Implementation
                                Using a Specific Allocator
                                Custom Allocators
                                Extension Allocators
                                auto_ptr
                                Limitations
                                Use in Containers
                                shared_ptr
                                Requirements
                                Design Issues
                                Implementation
                                Use
                                Acknowledgments
                                12. Traits
                                Prev Up Next
                                Adding Data to Exceptions Home Chapter 9. Functors
                                
diff --git a/libstdc++-v3/doc/html/manual/vector.html b/libstdc++-v3/doc/html/manual/vector.html
index 8ff38bdd149..8f554385943 100644
--- a/libstdc++-v3/doc/html/manual/vector.html
+++ b/libstdc++-v3/doc/html/manual/vector.html
@@ -1,7 +1,7 @@
 
 
-vector
                                vector
                                Prev Chapter 16. Sequences Next
                                vector
                                
-  
                                Space Overhead Management
                                
+vector
                                vector
                                Prev Chapter 16. Sequences Next
                                vector
                                
+  
                                Space Overhead Management
                                
      In this
      message to the list, Daniel Kostecky announced work on an
      alternate form of std::vector that would support
diff --git a/libstdc++-v3/doc/html/manual/verbose_termination.html b/libstdc++-v3/doc/html/manual/verbose_termination.html
index a6696882ff0..540e5a77577 100644
--- a/libstdc++-v3/doc/html/manual/verbose_termination.html
+++ b/libstdc++-v3/doc/html/manual/verbose_termination.html
@@ -1,6 +1,6 @@
 
 
-Verbose Terminate Handler
                                Verbose Terminate Handler
                                Prev Chapter 6. Termination Next
                                Verbose Terminate Handler
                                
+Verbose Terminate Handler
                                Verbose Terminate Handler
                                Prev Chapter 6. Termination Next
                                Verbose Terminate Handler
                                
       If you are having difficulty with uncaught exceptions and want a
       little bit of help debugging the causes of the core dumps, you can
       make use of a GNU extension, the verbose terminate handler.
@@ -38,7 +38,7 @@ int main(int argc)
 {
   std::set_terminate(__gnu_cxx::__verbose_terminate_handler);
   if (argc > 5)
-    throw argument_error(“argc is greater than 5!”);
+    throw argument_error(“argc is greater than 5!”);
   else
     throw argc;
 }
@@ -59,7 +59,7 @@ int main(int argc)
      abort(), of course.
    
                                
      This is the default termination handler; nothing need be done to
-     use it.  To go back to the previous “silent death”
+     use it.  To go back to the previous “silent death”
      method, simply include exception and
      cstdlib, and call
    
                                -- 
cgit v1.2.1