libstdc++: Add stable names to C++98 implementation-defined docs.

Stable names are based on C++03 standard document, and some of then were
changed since then.

libstdc++-v3/ChangeLog:

	* doc/html/manual/status.html: Regenerated the file.
	* doc/xml/manual/status_cxx1998.xml: Add stable name to
	each entry.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>

2 files changed, 108 insertions, 98 deletions

diff --git a/libstdc++-v3/doc/html/manual/status.html b/libstdc++-v3/doc/html/manual/status.html
index 5ca3521..f3d4a22 100644
--- a/libstdc++-v3/doc/html/manual/status.html
+++ b/libstdc++-v3/doc/html/manual/status.html
@@ -69,61 +69,65 @@ mainline GCC, not in any particular release.
      For each entry, we give the section number of the standard, when
      applicable.  This list is probably incomplet and inkorrekt.
    </p><p>
-     <span class="emphasis"><em>[1.9]/11 #3</em></span> If <code class="code">isatty(3)</code> is true, then
-      interactive stream support is implied.
+     <span class="emphasis"><em>1.9 [intro.execution]/11 #3</em></span> If <code class="code">isatty(3)</code>
+     is true, then interactive stream support is implied.
    </p><p>
-     <span class="emphasis"><em>[17.4.4.5]</em></span> Non-reentrant functions are probably best
-      discussed in the various sections on multithreading (see above).
-   </p><p><span class="emphasis"><em>[18.1]/4</em></span> The type of <code class="code">NULL</code> is described
-      under <a class="link" href="support.html#std.support.types.null" title="NULL">Support</a>.
-   </p><p><span class="emphasis"><em>[18.3]/8</em></span> Even though it's listed in the library
-      sections, libstdc++ has zero control over what the cleanup code hands
-      back to the runtime loader.  Talk to the compiler people.  :-)
-   </p><p><span class="emphasis"><em>[18.4.2.1]/5</em></span> (bad_alloc),
-      <span class="emphasis"><em>[18.5.2]/5</em></span> (bad_cast),
-      <span class="emphasis"><em>[18.5.3]/5</em></span> (bad_typeid),
-      <span class="emphasis"><em>[18.6.1]/8</em></span> (exception),
-      <span class="emphasis"><em>[18.6.2.1]/5</em></span> (bad_exception):  The <code class="code">what()</code>
-      member function of class <code class="code">std::exception</code>, and these other
-      classes publicly derived from it, returns the name of the
+     <span class="emphasis"><em>17.4.4.5 [lib.reentrancy]</em></span> Non-reentrant functions are
+     probably best discussed in the various sections on multithreading (see above).
+   </p><p><span class="emphasis"><em>18.1 [lib.support.types]/4</em></span> The type of
+      <code class="code">NULL</code> is described under
+      <a class="link" href="support.html#std.support.types.null" title="NULL">Support</a>.
+   </p><p><span class="emphasis"><em>18.3 [lib.support.start.term]/8</em></span> Even though it's
+      listed in the library sections, libstdc++ has zero control over what the
+      cleanup code hands back to the runtime loader.  Talk to the compiler people.
+      :-)
+   </p><p><span class="emphasis"><em>18.4.2.1 [lib.bad.alloc]/5</em></span> (bad_alloc),
+      <span class="emphasis"><em>18.5.2 [lib.bad.cast]/5</em></span> (bad_cast),
+      <span class="emphasis"><em>18.5.3 [lib.bad.typeid]/5</em></span> (bad_typeid),
+      <span class="emphasis"><em>18.6.1 [lib.exception]/8</em></span> (exception),
+      <span class="emphasis"><em>18.6.2.1 [lib.bad.exception]/5</em></span> (bad_exception):
+      The <code class="code">what()</code> member function of class <code class="code">std::exception</code>,
+      and these other classes publicly derived from it, returns the name of the
       class, e.g. <code class="literal">"std::bad_alloc"</code>.
-   </p><p><span class="emphasis"><em>[18.5.1]/7</em></span> The return value of
+   </p><p><span class="emphasis"><em>18.5.1 [lib.type.info]/7</em></span> The return value of
       <code class="code">std::type_info::name()</code> is the mangled type name.
       You will need to call <code class="code">c++filt</code> and pass the names as
       command-line parameters to demangle them, or call a
       <a class="link" href="ext_demangling.html" title="Chapter 28. Demangling">runtime demangler function</a>.
-   </p><p><span class="emphasis"><em>[20.1.5]/5</em></span> <span class="emphasis"><em>"Implementors are encouraged to
-      supply libraries that can accept allocators that encapsulate more
-      general memory models and that support non-equal instances.  In such
-      implementations, any requirements imposed on allocators by containers
-      beyond those requirements that appear in Table 32, and the semantics
-      of containers and algorithms when allocator instances compare
-      non-equal, are implementation-defined."</em></span>  There is experimental
-      support for non-equal allocators in the standard containers in C++98
-      mode. There are no additional requirements on allocators. It is undefined
-      behaviour to swap two containers if their allocators are not equal.
-   </p><p><span class="emphasis"><em>[21.1.3.1]/3,4</em></span>,
-      <span class="emphasis"><em>[21.1.3.2]/2</em></span>,
-      <span class="emphasis"><em>[21.3]/6 basic_string::iterator, basic_string::const_iterator</em></span>,
-      <span class="emphasis"><em>[23.*]'s foo::iterator</em></span>,
-      <span class="emphasis"><em>[27.*]'s foo::*_type</em></span>,
+   </p><p><span class="emphasis"><em>20.1.5 [lib.allocator.requirements]/5</em></span>
+      <span class="emphasis"><em>"Implementors are encouraged to supply libraries that can
+      accept allocators that encapsulate more general memory models and that
+      support non-equal instances.  In such implementations, any requirements
+      imposed on allocators by containers beyond those requirements that appear
+      in Table 32, and the semantics of containers and algorithms when allocator
+      instances compare non-equal, are implementation-defined."</em></span>
+      There is experimental support for non-equal allocators in the standard
+      containers in C++98  mode. There are no additional requirements on
+      allocators. It is undefined behaviour to swap two containers if their
+      allocators are not equal.
+   </p><p><span class="emphasis"><em>21.1.3.1 [lib.char.traits.specializations.char]/3,4</em></span>,
+      <span class="emphasis"><em>21.1.3.2 [lib.char.traits.specializations.wchar.t]/2</em></span>,
+      <span class="emphasis"><em>21.3 [lib.basic.string]/6 basic_string::iterator,
+      basic_string::const_iterator</em></span>,
+      <span class="emphasis"><em>23.* [lib.containers]'s foo::iterator</em></span>,
+      <span class="emphasis"><em>27.* [lib.input.output]'s foo::*_type</em></span>,
       <span class="emphasis"><em>others...</em></span>
       Nope, these types are called implementation-defined because you
       shouldn't be taking advantage of their underlying types.  Listing them
       here would defeat the purpose.  :-)
-   </p><p><span class="emphasis"><em>[21.1.3.1]/5</em></span> I don't really know about
-      the <span class="type">mbstate_t</span> stuff... see
+   </p><p><span class="emphasis"><em>21.1.3.1 [lib.char.traits.specializations.char]/5</em></span>
+      I don't really know about the <span class="type">mbstate_t</span> stuff... see
       the <a class="link" href="facets.html#std.localization.facet.codecvt" title="codecvt"><code class="code">codecvt</code>
       notes</a> for what does exist.
-   </p><p><span class="emphasis"><em>[22.*]</em></span> Anything and everything we have on locale
-      implementation will be described under
+   </p><p><span class="emphasis"><em>22.* [lib.localization]</em></span> Anything and everything
+      we have on locale implementation will be described under
       <a class="link" href="localization.html#std.localization.locales.locale" title="locale">Localization</a>.
-   </p><p><span class="emphasis"><em>[23.*]</em></span> All of the containers in this clause
-     define <span class="type">size_type</span> as <span class="type">std::size_t</span> and
+   </p><p><span class="emphasis"><em>23.* [lib.containers]</em></span> All of the containers in
+     this clause define <span class="type">size_type</span> as <span class="type">std::size_t</span> and
      <span class="type">difference_type</span> as <span class="type">std::ptrdiff_t</span>.
-   </p><p><span class="emphasis"><em>[26.2.8]/9</em></span> I have no idea what
-      <code class="code">complex&lt;T&gt;</code>'s <code class="code">pow(0,0)</code> returns.
-   </p><p><span class="emphasis"><em>[27.4.2.4]/2</em></span> Calling
+   </p><p><span class="emphasis"><em>26.2.8 [lib.complex.transcendentals/9</em></span> I have no
+      idea what <code class="code">complex&lt;T&gt;</code>'s <code class="code">pow(0,0)</code> returns.
+   </p><p><span class="emphasis"><em>27.4.2.4 [lib.ios.members.static/2</em></span> Calling
       <code class="code">std::ios_base::sync_with_stdio</code> after I/O has already been
       performed on the standard stream objects will
       flush the buffers, and 
@@ -131,16 +135,17 @@ mainline GCC, not in any particular release.
       the previously-written I/O is destroyed in this process depends mostly
       on the <code class="code">--enable-libio</code> choice:  for stdio, if the written
       data is already in the stdio buffer, the data may be completely safe!
-   </p><p><span class="emphasis"><em>[27.6.1.1.2]</em></span>,
-      <span class="emphasis"><em>[27.6.2.3]</em></span> The I/O sentry ctor and dtor can perform
-      additional work than the minimum required.  We are not currently taking
-      advantage of this yet.
-   </p><p><span class="emphasis"><em>[27.7.1.3]/16</em></span>,
-      <span class="emphasis"><em>[27.8.1.4]/10</em></span>
+   </p><p><span class="emphasis"><em>27.6.1.1.2 [lib.istream::sentry]</em></span>,
+      <span class="emphasis"><em>27.6.2.3 [lib.ostream::sentry]</em></span> The I/O sentry ctor
+      and dtor can perform additional work than the minimum required. We are
+      not currently taking  advantage of this yet.
+   </p><p><span class="emphasis"><em>27.7.1.3 [lib.stringbuf.virtuals]/16</em></span>,
+      <span class="emphasis"><em>27.8.1.4 [lib.filebuf.virtuals]/10</em></span>
       The effects of <code class="code">pubsetbuf/setbuf</code> are described in the
       <a class="link" href="io.html" title="Chapter 13.  Input and Output">Input and Output</a> chapter.
-   </p><p><span class="emphasis"><em>[27.8.1.4]/16</em></span> Calling <code class="code">fstream::sync</code> when
-      a get area exists will... whatever <code class="code">fflush()</code> does, I think.
+   </p><p><span class="emphasis"><em>27.8.1.4 [lib.filebuf.virtuals]/16</em></span> Calling
+      <code class="code">fstream::sync</code> when a get area exists will... whatever
+      <code class="code">fflush()</code> does, I think.
    </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="status.iso.2011"></a>C++ 2011</h3></div></div></div><p>
 <a id="status.iso.200x"></a> 
 This table is based on the table of contents of ISO/IEC
diff --git a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
index 6b84e7c..3cabf74 100644
--- a/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
+++ b/libstdc++-v3/doc/xml/manual/status_cxx1998.xml
@@ -1063,77 +1063,81 @@ mainline GCC, not in any particular release.
      applicable.  This list is probably incomplet and inkorrekt.
    </para>
    <para>
-     <emphasis>[1.9]/11 #3</emphasis> If <code>isatty(3)</code> is true, then
-      interactive stream support is implied.
+     <emphasis>1.9 [intro.execution]/11 #3</emphasis> If <code>isatty(3)</code>
+     is true, then interactive stream support is implied.
    </para>
    <para>
-     <emphasis>[17.4.4.5]</emphasis> Non-reentrant functions are probably best
-      discussed in the various sections on multithreading (see above).
+     <emphasis>17.4.4.5 [lib.reentrancy]</emphasis> Non-reentrant functions are
+     probably best discussed in the various sections on multithreading (see above).
    </para>
    <!-- [17.4.4.8]/3 says any function that doesn't have an exception-spec
 	can throw whatever we want; see also its footnote.  Let's list those
 	in the sections where the function itself occurs.
    -->
-   <para><emphasis>[18.1]/4</emphasis> The type of <code>NULL</code> is described
-      under <link linkend="std.support.types.null">Support</link>.
+   <para><emphasis>18.1 [lib.support.types]/4</emphasis> The type of
+      <code>NULL</code> is described under
+      <link linkend="std.support.types.null">Support</link>.
    </para>
-   <para><emphasis>[18.3]/8</emphasis> Even though it's listed in the library
-      sections, libstdc++ has zero control over what the cleanup code hands
-      back to the runtime loader.  Talk to the compiler people.  :-)
+   <para><emphasis>18.3 [lib.support.start.term]/8</emphasis> Even though it's
+      listed in the library sections, libstdc++ has zero control over what the
+      cleanup code hands back to the runtime loader.  Talk to the compiler people.
+      :-)
    </para>
-   <para><emphasis>[18.4.2.1]/5</emphasis> (bad_alloc),
-      <emphasis>[18.5.2]/5</emphasis> (bad_cast),
-      <emphasis>[18.5.3]/5</emphasis> (bad_typeid),
-      <emphasis>[18.6.1]/8</emphasis> (exception),
-      <emphasis>[18.6.2.1]/5</emphasis> (bad_exception):  The <code>what()</code>
-      member function of class <code>std::exception</code>, and these other
-      classes publicly derived from it, returns the name of the
+   <para><emphasis>18.4.2.1 [lib.bad.alloc]/5</emphasis> (bad_alloc),
+      <emphasis>18.5.2 [lib.bad.cast]/5</emphasis> (bad_cast),
+      <emphasis>18.5.3 [lib.bad.typeid]/5</emphasis> (bad_typeid),
+      <emphasis>18.6.1 [lib.exception]/8</emphasis> (exception),
+      <emphasis>18.6.2.1 [lib.bad.exception]/5</emphasis> (bad_exception):
+      The <code>what()</code> member function of class <code>std::exception</code>,
+      and these other classes publicly derived from it, returns the name of the
       class, e.g. <literal>"std::bad_alloc"</literal>.
    </para>
-   <para><emphasis>[18.5.1]/7</emphasis> The return value of
+   <para><emphasis>18.5.1 [lib.type.info]/7</emphasis> The return value of
       <code>std::type_info::name()</code> is the mangled type name.
       You will need to call <code>c++filt</code> and pass the names as
       command-line parameters to demangle them, or call a
       <link linkend="manual.ext.demangle">runtime demangler function</link>.
    </para>
-   <para><emphasis>[20.1.5]/5</emphasis> <emphasis>"Implementors are encouraged to
-      supply libraries that can accept allocators that encapsulate more
-      general memory models and that support non-equal instances.  In such
-      implementations, any requirements imposed on allocators by containers
-      beyond those requirements that appear in Table 32, and the semantics
-      of containers and algorithms when allocator instances compare
-      non-equal, are implementation-defined."</emphasis>  There is experimental
-      support for non-equal allocators in the standard containers in C++98
-      mode. There are no additional requirements on allocators. It is undefined
-      behaviour to swap two containers if their allocators are not equal.
+   <para><emphasis>20.1.5 [lib.allocator.requirements]/5</emphasis>
+      <emphasis>"Implementors are encouraged to supply libraries that can
+      accept allocators that encapsulate more general memory models and that
+      support non-equal instances.  In such implementations, any requirements
+      imposed on allocators by containers beyond those requirements that appear
+      in Table 32, and the semantics of containers and algorithms when allocator
+      instances compare non-equal, are implementation-defined."</emphasis>
+      There is experimental support for non-equal allocators in the standard
+      containers in C++98  mode. There are no additional requirements on
+      allocators. It is undefined behaviour to swap two containers if their
+      allocators are not equal.
    </para>
-   <para><emphasis>[21.1.3.1]/3,4</emphasis>,
-      <emphasis>[21.1.3.2]/2</emphasis>,
-      <emphasis>[21.3]/6 basic_string::iterator, basic_string::const_iterator</emphasis>,
-      <emphasis>[23.*]'s foo::iterator</emphasis>,
-      <emphasis>[27.*]'s foo::*_type</emphasis>,
+   <para><emphasis>21.1.3.1 [lib.char.traits.specializations.char]/3,4</emphasis>,
+      <emphasis>21.1.3.2 [lib.char.traits.specializations.wchar.t]/2</emphasis>,
+      <emphasis>21.3 [lib.basic.string]/6 basic_string::iterator,
+      basic_string::const_iterator</emphasis>,
+      <emphasis>23.* [lib.containers]'s foo::iterator</emphasis>,
+      <emphasis>27.* [lib.input.output]'s foo::*_type</emphasis>,
       <emphasis>others...</emphasis>
       Nope, these types are called implementation-defined because you
       shouldn't be taking advantage of their underlying types.  Listing them
       here would defeat the purpose.  :-)
    </para>
-   <para><emphasis>[21.1.3.1]/5</emphasis> I don't really know about
-      the <type>mbstate_t</type> stuff... see
+   <para><emphasis>21.1.3.1 [lib.char.traits.specializations.char]/5</emphasis>
+      I don't really know about the <type>mbstate_t</type> stuff... see
       the <link linkend="std.localization.facet.codecvt"><code>codecvt</code>
       notes</link> for what does exist.
    </para>
-   <para><emphasis>[22.*]</emphasis> Anything and everything we have on locale
-      implementation will be described under
+   <para><emphasis>22.* [lib.localization]</emphasis> Anything and everything
+      we have on locale implementation will be described under
       <link linkend="std.localization.locales.locale">Localization</link>.
    </para>
-   <para><emphasis>[23.*]</emphasis> All of the containers in this clause
-     define <type>size_type</type> as <type>std::size_t</type> and
+   <para><emphasis>23.* [lib.containers]</emphasis> All of the containers in
+     this clause define <type>size_type</type> as <type>std::size_t</type> and
      <type>difference_type</type> as <type>std::ptrdiff_t</type>.
    </para>
-   <para><emphasis>[26.2.8]/9</emphasis> I have no idea what
-      <code>complex&lt;T&gt;</code>'s <code>pow(0,0)</code> returns.
+   <para><emphasis>26.2.8 [lib.complex.transcendentals/9</emphasis> I have no
+      idea what <code>complex&lt;T&gt;</code>'s <code>pow(0,0)</code> returns.
    </para>
-   <para><emphasis>[27.4.2.4]/2</emphasis> Calling
+   <para><emphasis>27.4.2.4 [lib.ios.members.static/2</emphasis> Calling
       <code>std::ios_base::sync_with_stdio</code> after I/O has already been
       performed on the standard stream objects will
       flush the buffers, and <!-- this line might go away -->
@@ -1142,18 +1146,19 @@ mainline GCC, not in any particular release.
       on the <code>--enable-libio</code> choice:  for stdio, if the written
       data is already in the stdio buffer, the data may be completely safe!
    </para>
-   <para><emphasis>[27.6.1.1.2]</emphasis>,
-      <emphasis>[27.6.2.3]</emphasis> The I/O sentry ctor and dtor can perform
-      additional work than the minimum required.  We are not currently taking
-      advantage of this yet.
+   <para><emphasis>27.6.1.1.2 [lib.istream::sentry]</emphasis>,
+      <emphasis>27.6.2.3 [lib.ostream::sentry]</emphasis> The I/O sentry ctor
+      and dtor can perform additional work than the minimum required. We are
+      not currently taking  advantage of this yet.
    </para>
-   <para><emphasis>[27.7.1.3]/16</emphasis>,
-      <emphasis>[27.8.1.4]/10</emphasis>
+   <para><emphasis>27.7.1.3 [lib.stringbuf.virtuals]/16</emphasis>,
+      <emphasis>27.8.1.4 [lib.filebuf.virtuals]/10</emphasis>
       The effects of <code>pubsetbuf/setbuf</code> are described in the
       <link linkend="std.io">Input and Output</link> chapter.
    </para>
-   <para><emphasis>[27.8.1.4]/16</emphasis> Calling <code>fstream::sync</code> when
-      a get area exists will... whatever <code>fflush()</code> does, I think.
+   <para><emphasis>27.8.1.4 [lib.filebuf.virtuals]/16</emphasis> Calling
+      <code>fstream::sync</code> when a get area exists will... whatever
+      <code>fflush()</code> does, I think.
    </para>
 
 </section>