Update C++17 library status tables

	* doc/xml/manual/status_cxx2017.xml: Document P0024R2 status.
	* doc/html/*: Regenerate.

From-SVN: r270559

libstdc++-v3/ChangeLog

 2019-04-24  Jonathan Wakely  <jwakely@redhat.com>
 
+	* doc/xml/manual/status_cxx2017.xml: Document P0024R2 status.
+	* doc/html/*: Regenerate.
+
 	* include/bits/fs_path.h (operator<, operator<=, operator>)
 	(operator>=, operator==, operator!=): Make hidden friends, as per
 	LWG 3065.

libstdc++-v3/doc/html/faq.html

@@ -70,7 +70,7 @@
       Program crashes when using library code in a
       dynamically-loaded library
     </a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
-      “Memory leaks” in containers
+      “Memory leaks” in libstdc++
     </a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
       list::size() is O(n)!
     </a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
@@ -593,7 +593,7 @@
       Program crashes when using library code in a
       dynamically-loaded library
     </a></dt><dt>6.7. <a href="faq.html#faq.memory_leaks">
-      “Memory leaks” in containers
+      “Memory leaks” in libstdc++
     </a></dt><dt>6.8. <a href="faq.html#faq.list_size_on">
       list::size() is O(n)!
     </a></dt><dt>6.9. <a href="faq.html#faq.easy_to_fix">
@@ -708,15 +708,27 @@
     Link the executable:<br />
     <span class="command"><strong>g++ -fPIC -rdynamic -o foo ... -L. -lfoo -ldl</strong></span><br />
     </p></div></td></tr><tr class="question"><td align="left" valign="top"><a id="faq.memory_leaks"></a><a id="q-memory_leaks"></a><p><strong>6.7.</strong></p></td><td align="left" valign="top"><p>
-      <span class="quote">“<span class="quote">Memory leaks</span>”</span> in containers
-    </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><div class="note" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Note</h3><p>This answer is old and probably no longer be relevant.</p></div><p>
-    A few people have reported that the standard containers appear
+      <span class="quote">“<span class="quote">Memory leaks</span>”</span> in libstdc++
+    </p></td></tr><tr class="answer"><td align="left" valign="top"><a id="a-memory_leaks"></a></td><td align="left" valign="top"><p>
+    Since GCC 5.1.0, libstdc++ automatically allocates a pool
+    of a few dozen kilobytes on startup. This pool is used to ensure it's
+    possible to throw exceptions (such as <code class="classname">bad_alloc</code>)
+    even when <code class="code">malloc</code> is unable to allocate any more memory.
+    With some versions of <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>
+    this pool will be shown as "still reachable" when the process exits, e.g.
+    <code class="code">still reachable: 72,704 bytes in 1 blocks</code>.
+    This memory is not a leak, because it's still in use by libstdc++,
+    and the memory will be returned to the OS when the process exits.
+    Later versions of <span class="command"><strong>valgrind</strong></span> know how to free this
+    pool as the process exits, and so won't show any "still reachable" memory.
+    </p><p>
+    In the past, a few people reported that the standard containers appear
     to leak memory when tested with memory checkers such as
     <a class="link" href="http://valgrind.org/" target="_top"><span class="command"><strong>valgrind</strong></span></a>.
     Under some (non-default) 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
+    pool for later reuse, rather than deallocating it with <code class="code">delete</code>
+    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
     <a class="link" href="manual/debug.html#debug.memory" title="Memory Leak Hunting">Tips for memory leak hunting</a>

libstdc++-v3/doc/html/manual/api.html

@@ -28,11 +28,12 @@ Removal of <code class="filename">&lt;ext/tree&gt;</code>, moved to <code class=
 </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_320"></a><code class="constant">3.2</code></h3></div></div></div><p>
   </p><p>Symbol versioning introduced for shared library.</p><p>Removal of include <code class="filename">&lt;backward/strstream.h&gt;</code>.</p><p>Allocator changes. Change <code class="code">__malloc_alloc</code> to <code class="code">malloc_allocator</code> and <code class="code">__new_alloc</code> to <code class="code">new_allocator</code>. </p><p> For GCC releases from 2.95 through the 3.1 series, defining
    <code class="literal">__USE_MALLOC</code> on the gcc command line would change the
-   default allocation strategy to instead use <code class="code"> malloc</code> and
-   <code class="function">free</code>. For the 3.2 and 3.3 release series the same
+   default allocation strategy to instead use <code class="code">malloc</code> and
+   <code class="code">free</code>. For the 3.2 and 3.3 release series the same
    functionality was spelled <code class="literal">_GLIBCXX_FORCE_NEW</code>. From
-   GCC 3.4 onwards the functionality is enabled by setting
-   <code class="literal">GLIBCXX_FORCE_NEW</code> in the environment, see
+   GCC 3.4 onwards the default allocator uses <code class="code">new</code> anyway,
+   but for the optional pooling allocators the functionality is enabled by
+   setting <code class="literal">GLIBCXX_FORCE_NEW</code> in the environment, see
    <a class="link" href="mt_allocator.html" title="Chapter 20. The mt_allocator">the mt allocator chapter</a>
    for details.
    </p><p>Error handling in iostreams cleaned up, made consistent. </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="api.rel_330"></a><code class="constant">3.3</code></h3></div></div></div><p>

libstdc++-v3/doc/html/manual/backwards.html

@@ -484,8 +484,9 @@ No <code class="code">stream::attach(int fd)</code>
       stream-constructor.
     </p><p>
       An extension is available that implements this.
-      <code class="filename">&lt;ext/stdio_filebuf.h&gt;</code> contains a derived class called
-      <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00074.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>.
+      <code class="filename">&lt;ext/stdio_filebuf.h&gt;</code>
+      contains a derived class called
+      <code class="classname">__gnu_cxx::stdio_filebuf</code>.
       This class can be constructed from a C <code class="code">FILE*</code> or a file
       descriptor, and provides the <code class="code">fd()</code> function.
     </p><p>

libstdc++-v3/doc/html/manual/debug.html

@@ -53,40 +53,28 @@
   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 <a class="link" href="debug_mode.html" title="Chapter 17. Debug Mode">debug mode</a>.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug.memory"></a>Memory Leak Hunting</h3></div></div></div><p>
-  There are various third party memory tracing and debug utilities
+  On many targets GCC supports AddressSanitizer, a fast memory error detector,
+  which is enabled by the <code class="option">-fsanitize=address</code> option.
+</p><p>
+  There are also 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
   attempted, but includes <code class="code">mtrace</code>, <code class="code">valgrind</code>,
-  <code class="code">mudflap</code>, and the non-free commercial product
-  <code class="code">purify</code>. In addition, <code class="code">libcwd</code> has a
-  replacement for the global new and delete operators that can track
-  memory allocation and deallocation and provide useful memory
-  statistics.
-</p><p>
-  Regardless of the memory debugging tool being used, there is one
-  thing of great importance to keep in mind when debugging C++ code
-  that uses <code class="code">new</code> and <code class="code">delete</code>: there are
-  different kinds of allocation schemes that can be used by <code class="code">
-  std::allocator</code>. For implementation details, see the <a class="link" href="mt_allocator.html" title="Chapter 20. The mt_allocator">mt allocator</a> documentation and
-  look specifically for <code class="code">GLIBCXX_FORCE_NEW</code>.
-</p><p>
-  In a nutshell, the optional <code class="classname">mt_allocator</code>
-  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
-  termination.
+  <code class="code">mudflap</code> (no longer supported since GCC 4.9.0), ElectricFence,
+  and the non-free commercial product <code class="code">purify</code>.
+  In addition, <code class="code">libcwd</code>, jemalloc and TCMalloc have replacements
+  for the global <code class="code">new</code> and <code class="code">delete</code> operators
+  that can track memory allocation and deallocation and provide useful
+  memory statistics.
 </p><p>
   For valgrind, there are some specific items to keep in mind. First
   of all, use a version of valgrind that will work with current GNU
   C++ tools: the first that can do this is valgrind 1.0.4, but later
-  versions should work at least as well. Second of all, use a
-  completely unoptimized build to avoid confusing valgrind. Third, use
-  GLIBCXX_FORCE_NEW to keep extraneous pool allocation noise from
-  cluttering debug information.
+  versions should work better. Second, using an unoptimized build
+  might avoid confusing valgrind.
 </p><p>
-  Fourth, it may be necessary to force deallocation in other libraries
-  as well, namely the "C" library. On linux, this can be accomplished
+  Third, it may be necessary to force deallocation in other libraries
+  as well, namely the "C" library. On GNU/Linux, this can be accomplished
   with the appropriate use of the <code class="code">__cxa_atexit</code> or
   <code class="code">atexit</code> functions.
 </p><pre class="programlisting">
@@ -121,7 +109,29 @@
   up the runtime environment, library, and test file, might be:
 </p><pre class="programlisting">
    valgrind -v --num-callers=20 --leak-check=yes --leak-resolution=high --show-reachable=yes a.out
-</pre></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug.races"></a>Data Race Hunting</h3></div></div></div><p>
+</pre><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="debug.memory.mtalloc"></a>Non-memory leaks in Pool and MT allocators</h4></div></div></div><p>
+  There are different kinds of allocation schemes that can be used by
+  <code class="code">std::allocator</code>. Prior to GCC 3.4.0 the default was to use
+  a pooling allocator, <code class="classname">pool_allocator</code>,
+  which is still available as the optional
+  <code class="classname">__pool_alloc</code> extension.
+  Another optional extension, <code class="classname">__mt_alloc</code>,
+  is a high-performance pool allocator.
+</p><p>
+  In a suspect executable these pooling allocators can give
+  the mistaken impression that 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
+  termination.
+</p><p>
+  If you're using memory debugging tools on a program that uses
+  one of these pooling allocators, you can set the environment variable
+  <code class="literal">GLIBCXX_FORCE_NEW</code> to keep extraneous pool allocation
+  noise from cluttering debug information.
+  For more details, see the
+  <a class="link" href="mt_allocator.html" title="Chapter 20. The mt_allocator">mt allocator</a>
+  documentation and look specifically for <code class="code">GLIBCXX_FORCE_NEW</code>.
+</p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="debug.races"></a>Data Race Hunting</h3></div></div></div><p>
   All synchronization primitives used in the library internals need to be
   understood by race detectors so that they do not produce false reports.
 </p><p>

libstdc++-v3/doc/html/manual/ext_concurrency_impl.html

@@ -44,7 +44,7 @@ a POSIX-like interface.
 the current host. In libstdc++ implementation files,
 <bits/gthr.h> is used to select the proper gthreads file.
 </p><p>Within libstdc++ sources, all calls to underlying thread functionality
-use this layer. More detail as to the specific interface can be found in the source <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00883_source.html" target="_top">documentation</a>.
+use this layer. More detail as to the specific interface can be found in the source <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/index.html" target="_top">documentation</a>.
 </p><p>By design, the gthread layer is interoperable with the types,
 functions, and usage found in the usual &lt;pthread.h&gt; file,
 including <code class="code">pthread_t</code>, <code class="code">pthread_once_t</code>, <code class="code">pthread_create</code>,

libstdc++-v3/doc/html/manual/ext_io.html

@@ -34,11 +34,13 @@
 	 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.
-     </p></li><li class="listitem"><p>Beginning with 3.1, the extra <code class="code">filebuf</code> constructor and
+     </p></li><li class="listitem"><p>Beginning with 3.1, the extra
+	 <code class="classname">basic_filebuf</code> constructor and
 	 the <code class="code">fd()</code> function were removed from the standard
-	 filebuf.  Instead, <code class="code">&lt;ext/stdio_filebuf.h&gt;</code> contains
-	 a derived class called
-	 <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00074.html" target="_top"><code class="code">__gnu_cxx::stdio_filebuf</code></a>.
+	 filebuf.  Instead,
+	 <code class="filename">&lt;ext/stdio_filebuf.h&gt;</code>
+	 contains a derived class template called
+	 <code class="classname">__gnu_cxx::stdio_filebuf</code>.
 	 This class can be constructed from a C <code class="code">FILE*</code> or a file
 	 descriptor, and provides the <code class="code">fd()</code> function.
      </p></li></ul></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="ext_iterators.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="extensions.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="ext_demangling.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Chapter 27. Iterators </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> Chapter 29. Demangling</td></tr></table></div></body></html>
\ No newline at end of file

libstdc++-v3/doc/html/manual/parallel_mode_design.html

@@ -174,8 +174,8 @@ i. e. it is a singleton. It can be read and written by calling
 <code class="code">__gnu_parallel::_Settings::set</code>, respectively.
 Please note that the first call return a const object, so direct manipulation
 is forbidden.
-See <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01005.html" target="_top">
-  <code class="filename">settings.h</code></a>
+See <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/index.html" target="_top">
+  <code class="filename">&lt;parallel/settings.h&gt;</code></a>
 for complete details.
 </p><p>
 A small example of tuning the default:

libstdc++-v3/doc/html/manual/status.html

@@ -759,13 +759,14 @@ Feature-testing recommendations for C++</a>.
 	<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0031r0.html" target="_top">
 	P0031R0
 	</a>
-      </td><td align="center"> 7.1 </td><td align="left"><code class="code"> __cpp_lib_array_constexpr &gt;= 201603 </code></td></tr><tr bgcolor="#C8B0B0"><td align="left"> The Parallelism TS Should be Standardized	 </td><td align="left">
+      </td><td align="center"> 7.1 </td><td align="left"><code class="code"> __cpp_lib_array_constexpr &gt;= 201603 </code></td></tr><tr bgcolor="#B0B0B0"><td align="left"> The Parallelism TS Should be Standardized	 </td><td align="left">
 	<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0024r2.html" target="_top">
 	P0024R2
 	</a>
-      </td><td align="center"> No </td><td align="left"><code class="code"> __has_include(&lt;execution&gt;) </code>,
+      </td><td align="center"> 9.1 </td><td align="left"><code class="code"> __has_include(&lt;execution&gt;) </code>,
 	     <code class="code"> __cpp_lib_execution &gt;= 201603 </code>,
 	     <code class="code"> __cpp_lib_parallel_algorithm &gt;= 201603 </code>
+             (requires linking with <code class="code">-ltbb</code>, see Note 3)
       </td></tr><tr><td align="left"> An algorithm to "clamp" a value between a pair of boundary values </td><td align="left">
 	<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0025r0.html" target="_top">
 	P0025R0
@@ -783,7 +784,7 @@ Feature-testing recommendations for C++</a>.
 	P0226R1
 	</a>
       </td><td align="center"> 7.1 </td><td align="left"><code class="code"> __cpp_lib_math_special_functions &gt;= 201603 </code>
-	     (see Note 3)
+	     (see Note 4)
       </td></tr><tr><td align="left">Adopt the File System TS for C++17	 </td><td align="left">
 	<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0218r1.html" target="_top">
 	P0218R1
@@ -846,7 +847,11 @@ Note 2: This feature is supported in older releases but the
 <code class="code">__cpp_lib</code> macro is not defined to the right value
 (or not defined at all) until the version shown in parentheses.
 </p><p>
-Note 3: The mathematical special functions are enabled in C++17 mode from
+Note 3: The Parallel Algorithms have an external dependency on Intel TBB 2018
+or later. If the <code class="filename">&lt;execution&gt;</code>
+header is included then <code class="code">-ltbb</code> must be used to link to TBB.
+</p><p>
+Note 4: The mathematical special functions are enabled in C++17 mode from
 GCC 7.1 onwards. For GCC 6.x or for C++11/C++14 define
 <code class="code">__STDCPP_WANT_MATH_SPEC_FUNCS__</code> to a non-zero value
 and test for <code class="code">__STDCPP_MATH_SPEC_FUNCS__ &gt;= 201003L</code>.
@@ -1245,11 +1250,11 @@ Feature-testing recommendations for C++</a>.
         <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0608r3.html" target="_top">
 	P0608R3
 	</a>
-      </td><td align="center"> </td><td align="left"> </td></tr><tr bgcolor="#C8B0B0"><td align="left">  <code class="code">visit&lt;R&gt;</code>: Explicit Return Type for <code class="code">visit</code> </td><td align="left">
+      </td><td align="center"> </td><td align="left"> </td></tr><tr><td align="left">  <code class="code">visit&lt;R&gt;</code>: Explicit Return Type for <code class="code">visit</code> </td><td align="left">
         <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0655r1.pdf" target="_top">
 	P0655R1
 	</a>
-      </td><td align="center"> </td><td align="left"> </td></tr><tr><td align="left">  <code class="code">std::function</code> move constructor should be <code class="code">noexcept</code> </td><td align="left">
+      </td><td align="center"> 9.1 </td><td align="left"> </td></tr><tr><td align="left">  <code class="code">std::function</code> move constructor should be <code class="code">noexcept</code> </td><td align="left">
         <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0771r1.pdf" target="_top">
 	P0771R1
 	</a>

libstdc++-v3/doc/html/manual/support.html

@@ -56,8 +56,8 @@
     The header <code class="filename">limits</code> defines
     traits classes to give access to various implementation
     defined-aspects of the fundamental types. The traits classes --
-    fourteen in total -- are all specializations of the template class
-    <code class="classname">numeric_limits</code>, documented <a class="link" href="http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00593.html" target="_top">here</a>
+    fourteen in total -- are all specializations of the class template
+    <code class="classname">numeric_limits</code>
     and defined as follows:
     </p><pre class="programlisting">
    template&lt;typename T&gt;

libstdc++-v3/doc/xml/manual/status_cxx2017.xml

@@ -633,17 +633,18 @@ Feature-testing recommendations for C++</link>.
     </row>
 
     <row>
-      <?dbhtml bgcolor="#C8B0B0" ?>
+      <?dbhtml bgcolor="#B0B0B0" ?>
       <entry> The Parallelism TS Should be Standardized	 </entry>
       <entry>
 	<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0024r2.html">
 	P0024R2
 	</link>
       </entry>
-      <entry align="center"> No </entry>
+      <entry align="center"> 9.1 </entry>
       <entry><code> __has_include(&lt;execution&gt;) </code>,
 	     <code> __cpp_lib_execution >= 201603 </code>,
 	     <code> __cpp_lib_parallel_algorithm >= 201603 </code>
+             (requires linking with <code>-ltbb</code>, see Note 3)
       </entry>
     </row>
 
@@ -689,7 +690,7 @@ Feature-testing recommendations for C++</link>.
       </entry>
       <entry align="center"> 7.1 </entry>
       <entry><code> __cpp_lib_math_special_functions >= 201603 </code>
-	     (see Note 3)
+	     (see Note 4)
       </entry>
     </row>
 
@@ -841,7 +842,13 @@ Note 2: This feature is supported in older releases but the
 </para>
 
 <para>
-Note 3: The mathematical special functions are enabled in C++17 mode from
+Note 3: The Parallel Algorithms have an external dependency on Intel TBB 2018
+or later. If the <filename class="headerfile">&lt;execution&gt;</filename>
+header is included then <code>-ltbb</code> must be used to link to TBB.
+</para>
+
+<para>
+Note 4: The mathematical special functions are enabled in C++17 mode from
 GCC 7.1 onwards. For GCC 6.x or for C++11/C++14 define
 <code>__STDCPP_WANT_MATH_SPEC_FUNCS__</code> to a non-zero value
 and test for <code>__STDCPP_MATH_SPEC_FUNCS__ >= 201003L</code>.