Merge branch 'master' into no-unique-address

Author: rjmccall

abi-eh.html

@@ -71,7 +71,7 @@ <h3> Introduction </h3>
 
 <p>
 This specification is based on the general model described roughly in the
-<a href="http://download.intel.com/design/Itanium/Downloads/245358.pdf">
+<a href="https://www.intel.com/content/dam/www/public/us/en/documents/guides/itanium-software-runtime-architecture-guide.pdf">
 Itanium Software Conventions and Runtime Architecture Guide</a>.
 However, the Level I (base ABI) specification here contradicts that
 document in some particulars,
@@ -160,7 +160,7 @@ <h3> Level I. Base ABI </h3>
 facilities are built.
 We assume as a basis the unwind descriptor tables described in the base
 <a
-href="http://www.intel.com/design/itanium/downloads/245358.htm">Itanium
+href="https://www.intel.com/content/dam/www/public/us/en/documents/guides/itanium-software-runtime-architecture-guide.pdf">Itanium
 Software Conventions &amp; Runtime Architecture Guide</a>. 
 Our focus here will on the APIs for accessing those structures.
 

abi.html

@@ -163,8 +163,8 @@ <h3><a href="#definitions"> 1.1 Definitions </a></h3>
 <p>
 <dt> <i>empty class</i> </dt>
 <dd>
-A class with no non-static data members other than zero-width bitfields
-and empty data members,
+A class with no non-static data members,
+no unnamed bit-fields other than zero-width bit-fields and empty data members,
 no virtual functions, no virtual base classes,
 and no non-empty non-virtual proper base classes.
 
@@ -237,7 +237,7 @@ <h3><a href="#definitions"> 1.1 Definitions </a></h3>
 A class that contains a virtual pointer, but no other data except
 (possibly) virtual bases.  In particular, it:
 <ul>
-<li> has no non-static data members other than zero-width bitfields,
+<li> has no non-static data members and no non-zero-width unnamed bit-fields,
 <li> has no direct base classes that are not either empty, nearly empty,
      or virtual,
 <li> has at most one non-virtual, nearly empty direct base class, and
@@ -273,20 +273,18 @@ <h3><a href="#definitions"> 1.1 Definitions </a></h3>
 <dd>
 <p>
 In general, a type is considered a POD for the purposes of layout if
-it is a POD type (in the sense of ISO C++ [basic.types]).
-However, a type is not considered to be a POD for the purpose of layout
-if it is:
+it is a POD type (in the sense of ISO C++ [basic.types]). However, a
+type is not considered to be a POD for the purpose of layout if it is:
 <ul>
 <li>a POD-struct or POD-union (in the sense of ISO C++ [class]) with a
-bitfield member whose declared width is wider than the declared type
-of the bitfield, or
+bit-field whose declared width is wider than the declared type
+of the bit-field, or
 <li>an array type whose element type is not a POD for the purpose of layout, or
 <li>a POD-struct with one or more potentially-overlapping non-static
 data members.
 </ul>
-Where references
-to the ISO C++ are made in this paragraph, the Technical Corrigendum 1
-version of the standard is intended.
+Where references to the ISO C++ are made in this paragraph, the Technical
+Corrigendum 1 version of the standard is intended.
 </p>
 
 <p>
@@ -564,8 +562,8 @@ <h3><a href="#docs"> 1.5 Base Documents </a></h3>
 notably including register usage, subprogram calling conventions, and
 stack unwind facilities, under all systems.
 Available from the Intel Itanium software developer website,
-<a href="http://download.intel.com/design/Itanium/Downloads/245358.pdf">
-http://download.intel.com/design/Itanium/Downloads/245358.pdf</a>.
+<a href="https://www.intel.com/content/dam/www/public/us/en/documents/guides/itanium-software-runtime-architecture-guide.pdf">
+https://www.intel.com/content/dam/www/public/us/en/documents/guides/itanium-software-runtime-architecture-guide.pdf</a>.
 Included by reference in this ABI.
 
 <p>
@@ -796,13 +794,13 @@ <h3><a href="#class-types"> 2.4 Non-POD Class Types </a></h3>
 <p>
 For each data component D (first the primary base of C, if any, then
 the non-primary, non-virtual direct base classes in declaration order,
-then the non-static data members and unnamed bitfields in declaration
+then the non-static data members and unnamed bit-fields in declaration
 order), allocate as follows:
 
   <ol type=1>
 
   <p>
-  <li> If D is a (possibly unnamed) bitfield whose declared type is 
+  <li> If D is a (possibly unnamed) bit-field whose declared type is
        <code>T</code> and whose declared width is <code>n</code> bits:
 
        <p>
@@ -813,13 +811,13 @@ <h3><a href="#class-types"> 2.4 Non-POD Class Types </a></h3>
        <p>
        <li>
        If <code>sizeof(T)*8 >= n</code>,
-       the bitfield is allocated as required by the underlying C psABI,
-       subject to the constraint that a bitfield is never placed in the 
+       the bit-field is allocated as required by the underlying C psABI,
+       subject to the constraint that a bit-field is never placed in the
        tail padding of a base class of C.
 
        <p>
        If dsize(C) > 0, and the byte at offset dsize(C) - 1 is
-       partially filled by a bitfield, and that bitfield is also a
+       partially filled by a bit-field, and that bit-field is also a
        data member declared in C (but not in one of C's proper base
        classes), the next available bits are the unfilled bits at
        offset dsize(C) - 1.  Otherwise, the next available bits are at
@@ -833,10 +831,10 @@ <h3><a href="#class-types"> 2.4 Non-POD Class Types </a></h3>
        If <code>sizeof(T)*8 < n</code>,
        let T' be the largest integral POD type with
        <code>sizeof(T')*8 <= n</code>.
-       The bitfield is allocated starting at the next offset aligned
+       The bit-field is allocated starting at the next offset aligned
        appropriately for T', with length n bits.
        The first <code>sizeof(T)*8</code> bits are used to hold the
-       value of the bitfield,
+       value of the bit-field,
        followed by <code>n - sizeof(T)*8</code> bits of padding.
 	<p>
 	Update align(C) to max (align(C), align(T')).
@@ -845,7 +843,7 @@ <h3><a href="#class-types"> 2.4 Non-POD Class Types </a></h3>
        <p>
        In either case,
        update dsize(C) to include the last byte
-       containing (part of) the bitfield,
+       containing (part of) the bit-field,
        and update sizeof(C) to max(sizeof(C),dsize(C)).
 
   <p>
@@ -4085,8 +4083,9 @@ <h4><a href="#mangling-general"> 5.1.1 General </a></h4>
 or <code>Type?</code> for an unknown data type.
 
 <p>
-Grammar productions beginning with '$' are reserved for private implementation
-use.  Names produced using such extensions are inherently non-portable.
+Mangled names containing '<tt>$</tt>' or '<tt>.</tt>' are reserved for
+private implementation use. Names produced using such extensions are
+inherently non-portable and should be given internal linkage where possible.
 
 <p>
 <a name="mangling-structure">
@@ -4097,6 +4096,7 @@ <h4><a href="#mangling-structure"> 5.1.2 General Structure </a></h4>
 Mangled names have the general structure:
 <pre><font color=blue><code>
     &lt;<a name="mangle.mangled-name">mangled-name</a>&gt; ::= _Z &lt;<a href="#mangle.encoding">encoding</a>&gt;
+                   ::= _Z &lt;<a href="#mangle.encoding">encoding</a>&gt; . &lt;vendor-specific suffix&gt;
     &lt;<a name="mangle.encoding">encoding</a>&gt; ::= &lt;<i>function</i> <a href="#mangle.name">name</a>&gt; &lt;<a href="#mangle.bare-function-type">bare-function-type</a>&gt;
 	       ::= &lt;<i>data</i> <a href="#mangle.name">name</a>&gt;
 	       ::= &lt;<a href="#mangle.special-name">special-name</a>&gt;
@@ -4114,6 +4114,13 @@ <h4><a href="#mangling-structure"> 5.1.2 General Structure </a></h4>
 parameters).
 The type is omitted for variables and static data members.
 
+<p>
+A <code>&lt;<a href="#mangle.mangled-name">mangled-name</a>&gt;</code>
+containing a period represents a vendor-specific version or portion
+of the entity named by the <code>&lt;<a href="#mangle.encoding">encoding</a>&gt;</code>
+prior to the first period. There is no restriction on the characters
+that may be used in the suffix following the period.
+
 <a name="mangle.anonymous">
 <h5><a href="#mangling.anonymous">Anonymous entities</a></h5>
 
@@ -5200,7 +5207,7 @@ <h4><a href="#expressions">5.1.6 Expressions</a></h4>
                  ::= L &lt;<i>nullptr</i> <a href="#mangle.type">type</a>&gt; E                                 # nullptr literal (i.e., "LDnE")
                  ::= L &lt;<i>pointer</i> <a href="#mangle.type">type</a>&gt; 0 E                               # null pointer template argument
 		 ::= L &lt;<a href="#mangle.type">type</a>&gt; &lt;<i>real-part</i> <a href="#mangle.float">float</a>&gt; _ &lt;<i>imag-part</i> <a href="#mangle.float">float</a>&gt; E   # complex floating point literal (C 2000)
-                 ::= L &lt;<a href="#mangle.mangled-name">mangled-name</a>&gt; E                                 # external name
+                 ::= L _Z &lt;<a href="#mangle.encoding">encoding</a>&gt; E                                  # external name
 
   &lt;<a name="mangle.braced-expression">braced-expression</a>&gt; ::= &lt;<a href="#mangle.expression">expression</a>&gt;
                       ::= di &lt;<i>field</i> <a href="#mangle.source-name">source-name</a>&gt; &lt;<a href="#mangle.braced-expression">braced-expression</a>&gt;    # .name = expr
@@ -5238,7 +5245,7 @@ <h5><a href="#mangling.literal">5.1.6.1 Literals</a></h5>
 Floating-point literals are encoded using a fixed-length lowercase
 hexadecimal string corresponding to the internal representation,
 high-order bytes first.  For example: "Lf bf800000 E" is -1.0f on
-platforms conforming to IEEE 758.
+platforms conforming to IEEE 754.
 
 <p>
 The encoding for a literal of an enumerated type is the encoding of the
@@ -5286,7 +5293,7 @@ <h5><a href="#mangling.declaration-reference">5.1.6.2 References to declared ent
 <p>
 When encoding template signatures, a name appearing in the source code
 cannot always be resolved to a specific entity: In such cases the
-<code>&lt;<a href="#mangle.mangled-name">mangled-name</a>&gt;</code> production (via 
+<code>&lt;<a href="#mangle.encoding">encoding</a>&gt;</code> production (via
 <code>&lt;<a href="#mangle.expr-primary">expr-primary</a>&gt;</code>) does not apply, and instead the
 <code>&lt;<a href="#mangle.unresolved-name">unresolved-name</a>&gt;</code> encoding is used.  For example:
 <code><pre>
@@ -5356,11 +5363,11 @@ <h4><a href="#mangling-scope">5.1.7 Scope Encoding</a></h4>
 relative to the function, and an optional discriminator within the
 function:
 
-<code><pre><font color=blue>  &lt;<a name="mangle.local-name">local-name</a>&gt; := Z &lt;<i>function</i> <a href="#mangle.encoding">encoding</a>&gt; E &lt;<i>entity</i> <a href="#mangle.name">name</a>&gt; [&lt;<a href="#mangle.discriminator">discriminator</a>&gt;]
-               := Z &lt;<i>function</i> <a href="#mangle.encoding">encoding</a>&gt; E s [&lt;<a href="#mangle.discriminator">discriminator</a>&gt;]
+<code><pre><font color=blue>  &lt;<a name="mangle.local-name">local-name</a>&gt; ::= Z &lt;<i>function</i> <a href="#mangle.encoding">encoding</a>&gt; E &lt;<i>entity</i> <a href="#mangle.name">name</a>&gt; [&lt;<a href="#mangle.discriminator">discriminator</a>&gt;]
+               ::= Z &lt;<i>function</i> <a href="#mangle.encoding">encoding</a>&gt; E s [&lt;<a href="#mangle.discriminator">discriminator</a>&gt;]
 
-  &lt;<a name="mangle.discriminator">discriminator</a>&gt; := _ &lt;<i>non-negative</i> <a href="#mangle.number">number</a>&gt;      # when number < 10
-                  := __ &lt;<i>non-negative</i> <a href="#mangle.number">number</a>&gt; _   # when number >= 10
+  &lt;<a name="mangle.discriminator">discriminator</a>&gt; ::= _ &lt;<i>non-negative</i> <a href="#mangle.number">number</a>&gt;      # when number < 10
+                  ::= __ &lt;<i>non-negative</i> <a href="#mangle.number">number</a>&gt; _   # when number >= 10
 </font></pre></code>
 
 <p>The enclosing function is the closest function enclosing the
@@ -5556,7 +5563,7 @@ <h4><a href="#closure-types">5.1.8 Closure Types (Lambdas)</a></h4>
 <p>
 If the context is a default argument (of a member function parameter)
 appearing in a class definition, the closure class and its members are encoded as follows:
-<code><pre><font color=blue>  &lt;<a href="#mangle.local-name">local-name</a>&gt; := Z &lt;<i>function</i> <a href="#mangle.encoding">encoding</a>&gt; Ed [ &lt;<i>parameter</i> <a href="#mangle.number">number</a>&gt; ] _ &lt;<i>entity</i> <a href="#mangle.name">name</a>&gt;
+<code><pre><font color=blue>  &lt;<a href="#mangle.local-name">local-name</a>&gt; ::= Z &lt;<i>function</i> <a href="#mangle.encoding">encoding</a>&gt; Ed [ &lt;<i>parameter</i> <a href="#mangle.number">number</a>&gt; ] _ &lt;<i>entity</i> <a href="#mangle.name">name</a>&gt;
 </font></pre></code>
 The parameter number is omitted for the last parameter, 0 for the second-to-last parameter, 1 for the third-to-last parameter, etc. 
 The <code>&lt;<i>entity</i> <a href="#mangle.name">name</a>&gt;</code> will of course contain a
@@ -5584,7 +5591,7 @@ <h4><a href="#closure-types">5.1.8 Closure Types (Lambdas)</a></h4>
 member (static or nonstatic), inline variable, or variable template,
 it is encoded in a qualified name with a
 final <code>&lt;<a href="#mangle.prefix">prefix</a>&gt;</code> of the form:
-<code><pre><font color=blue>  &lt;data-member-prefix&gt; := &lt;<i>member</i> <a href="#mangle.source-name">source-name</a>&gt; [&lt;<a href="#mangle.template-args">template-args</a>&gt;] M
+<code><pre><font color=blue>  &lt;data-member-prefix&gt; ::= &lt;<i>member</i> <a href="#mangle.source-name">source-name</a>&gt; [&lt;<a href="#mangle.template-args">template-args</a>&gt;] M
 </font></pre></code>
 where the <code>&lt;<a href="#mangle.template-args">template-args</a>&gt;</code>
 is present for a closure type within a variable template specialization
@@ -6118,7 +6125,7 @@ <h2><a name="revisions">Appendix R: Revision History</a></h2>
   Reverse treatment of ambiguous arguments to __cxa_demangle (3.4).</p>
 
 <p class="revision"><span class="date">[041118]</span>
-  Clarify the layout of bitfields.</p>
+  Clarify the layout of bit-fields.</p>
 
 <p class="revision"><span class="date">[041025]</span>
   Indicate that the TC1 definition of POD is intended in the section
@@ -6361,20 +6368,20 @@ <h2><a name="revisions">Appendix R: Revision History</a></h2>
   Add thunk definition.
   Revise inheritance graph order definition.
   Fix member function pointer description (no division by two).
-  Move bitfield allocation description (much modified)
+  Move bit-field allocation description (much modified)
   to the non-virtual-base allocation description.
   Replace virtual function calling convention description.</p>
 
 <p class="revision"><span class="date">[000228]</span>
   Add thunk definition.
   Revise inheritance graph order definition.
   Fix member function pointer description (no division by two).
-  Move bitfield allocation description (much modified)
+  Move bit-field allocation description (much modified)
   to the non-virtual-base allocation description.
   Replace virtual function calling convention description.</p>
 
 <p class="revision"><span class="date">[000217]</span>
-  Add excess-size bitfield specification.
+  Add excess-size bit-field specification.
   Add namespace/header section.
   Touch up array new cookies.
   Remove construction vtable example to new file.