diff --git a/libstdc++-v3/doc/xml/faq.xml b/libstdc++-v3/doc/xml/faq.xml
index e2cf49a..1408bd2 100644
--- a/libstdc++-v3/doc/xml/faq.xml
+++ b/libstdc++-v3/doc/xml/faq.xml
@@ -935,8 +935,8 @@
     A few people have reported that the standard containers appear
     to leak memory when tested with memory checkers such as
     <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://valgrind.org/">valgrind</link>.
-    The library's default allocators keep free memory in a pool
-    for later reuse, rather than returning it to the OS.  Although
+    Under some configurations the library's allocators keep free memory in a
+    pool for later reuse, rather than returning it to the OS.  Although
     this memory is always reachable by the library and is never
     lost, memory debugging tools can report it as a leak.  If you
     want to test the library for memory leaks please read
diff --git a/libstdc++-v3/doc/xml/manual/allocator.xml b/libstdc++-v3/doc/xml/manual/allocator.xml
index 55dc808..911aaf5 100644
--- a/libstdc++-v3/doc/xml/manual/allocator.xml
+++ b/libstdc++-v3/doc/xml/manual/allocator.xml
@@ -103,7 +103,7 @@
     implements the simple operator new and operator delete semantics,
     while <classname>__gnu_cxx::malloc_allocator</classname>
     implements much the same thing, only with the C language functions
-    <function>std::malloc</function> and <function>free</function>.
+    <function>std::malloc</function> and <function>std::free</function>.
   </para>
 
   <para>
@@ -236,12 +236,12 @@
 
     <para>
       In use, <classname>allocator</classname> may allocate and
-      deallocate using implementation-specified strategies and
-      heuristics. Because of this, every call to an allocator object's
+      deallocate using implementation-specific strategies and
+      heuristics. Because of this, a given call to an allocator object's
       <function>allocate</function> member function may not actually
-      call the global operator new. This situation is also duplicated
-      for calls to the <function>deallocate</function> member
-      function.
+      call the global <code>operator new</code> and a given call to
+      to the <function>deallocate</function> member function may not
+      call <code>operator delete</code>.
     </para>
 
    <para>
@@ -250,7 +250,7 @@
 
    <para>
      In particular, this can make debugging memory errors more
-     difficult, especially when using third party tools like valgrind or
+     difficult, especially when using third-party tools like valgrind or
      debug versions of <function>new</function>.
    </para>
 
@@ -258,9 +258,9 @@
      There are various ways to solve this problem. One would be to use
      a custom allocator that just called operators
      <function>new</function> and <function>delete</function>
-     directly, for every allocation. (See
+     directly, for every allocation. (See the default allocator,
      <filename>include/ext/new_allocator.h</filename>, for instance.)
-     However, that option would involve changing source code to use
+     However, that option may involve changing source code to use
      a non-default allocator. Another option is to force the
      default allocator to remove caching and pools, and to directly
      allocate with every call of <function>allocate</function> and
@@ -271,8 +271,8 @@
 
 
    <para>
-     To globally disable memory caching within the library for the
-     default allocator, merely set
+     To globally disable memory caching within the library for some of
+     the optional non-default allocators, merely set
      <constant>GLIBCXX_FORCE_NEW</constant> (with any value) in the
      system's environment before running the program. If your program
      crashes with <constant>GLIBCXX_FORCE_NEW</constant> in the
@@ -472,7 +472,8 @@
        <para>
 	 A high-performance fixed-size allocator with
 	 exponentially-increasing allocations. It has its own
-	 documentation, found <link linkend="manual.ext.allocator.mt">here</link>.
+	 <link linkend="manual.ext.allocator.mt">chapter</link> 
+         in the documentation.
        </para>
      </listitem>
 
@@ -483,7 +484,8 @@
        <para>
 	 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 <link linkend="manual.ext.allocator.bitmap">here</link>.
+	 <link linkend="manual.ext.allocator.bitmap">chapter</link>
+         in the documentation.
        </para>
      </listitem>
    </orderedlist>
diff --git a/libstdc++-v3/doc/xml/manual/debug.xml b/libstdc++-v3/doc/xml/manual/debug.xml
index 0a24c96..7a984bb 100644
--- a/libstdc++-v3/doc/xml/manual/debug.xml
+++ b/libstdc++-v3/doc/xml/manual/debug.xml
@@ -116,13 +116,13 @@
   thing of great importance to keep in mind when debugging C++ code
   that uses <code>new</code> and <code>delete</code>: there are
   different kinds of allocation schemes that can be used by <code>
-  std::allocator </code>. For implementation details, see the <link linkend="manual.ext.allocator.mt">mt allocator</link> documentation and
+  std::allocator</code>. For implementation details, see the <link linkend="manual.ext.allocator.mt">mt allocator</link> documentation and
   look specifically for <code>GLIBCXX_FORCE_NEW</code>.
 </para>
 
 <para>
-  In a nutshell, the default allocator used by <code>
-  std::allocator</code> is a high-performance pool allocator, and can
+  In a nutshell, the optional <classname>mt_allocator</classname>
+  is a high-performance pool allocator, and can
   give the mistaken impression that in a suspect executable, memory is
   being leaked, when in reality the memory "leak" is a pool being used
   by the library's allocator and is reclaimed after program
diff --git a/libstdc++-v3/doc/xml/manual/evolution.xml b/libstdc++-v3/doc/xml/manual/evolution.xml
index 145c11f..ce8c14e 100644
--- a/libstdc++-v3/doc/xml/manual/evolution.xml
+++ b/libstdc++-v3/doc/xml/manual/evolution.xml
@@ -81,8 +81,11 @@ Removal of <filename class="headerfile">ext/tree</filename>, moved to <filename
    <para> For GCC releases from 2.95 through the 3.1 series, defining
    <literal>__USE_MALLOC</literal> on the gcc command line would change the
    default allocation strategy to instead use <code> malloc</code> and
-   <function>free</function>. (This same functionality is now spelled <literal>_GLIBCXX_FORCE_NEW</literal>, see
-   <link linkend="manual.intro.using.macros">this page</link>
+   <function>free</function>. For the 3.2 and 3.3 release series the same
+   functionality was spelled <literal>_GLIBCXX_FORCE_NEW</literal>. From
+   GCC 3.4 onwards the functionality is enabled by setting
+   <literal>GLIBCXX_FORCE_NEW</literal> in the environment, see
+   <link linkend="manual.ext.allocator.mt">the mt allocator chapter</link>
    for details.
    </para>
 
diff --git a/libstdc++-v3/doc/xml/manual/using.xml b/libstdc++-v3/doc/xml/manual/using.xml
index 74a08ec..61190f5 100644
--- a/libstdc++-v3/doc/xml/manual/using.xml
+++ b/libstdc++-v3/doc/xml/manual/using.xml
@@ -847,17 +847,6 @@ g++ -Winvalid-pch -I. -include stdc++.h -H -g -O2 hello.cc -o test.exe
     </para>
     </listitem></varlistentry>
 
-    <varlistentry><term><code>_GLIBCXX_FORCE_NEW</code></term>
-    <listitem>
-      <para>
-	Undefined by default. When defined, memory allocation and
-	allocators controlled by libstdc++ call operator new/delete
-	without caching and pooling. Configurable via
-	<code>--enable-libstdcxx-allocator</code>. ABI-changing.
-      </para>
-    </listitem></varlistentry>
-
-
     <varlistentry><term><code>_GLIBCXX_CONCEPT_CHECKS</code></term>
     <listitem>
       <para>
