Skip to content

R
riscv-gcc-1
Commit 7c3e085e by Jonathan Wakely Committed by Jonathan Wakely
Options

Update C++17 library status tables 

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

From-SVN: r270559
parent f90b16c4
Showing with 101 additions and 59 deletions
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,
&lt;bits/gthr.h&gt; 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>.
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment