cxx-open.html

<HTML>

<HEAD>
<title>C++ ABI Open Issues</title>

<link rel=stylesheet href=small-table.css type="text/css">
<link rel=stylesheet href=code.css type="text/css">

<hr>

<font size=6><i><b>
<p>
C++ ABI Open Issues
</b></i></font>

<font size=-1>
<p>
<i>Revised 17 November 2000</i>

</center>

</HEAD>

<BODY>

<p> <hr> <p>
<h3> Revisions </h3>

<p>
<font color=blue>[001110]</font>
Reopened and reclosed <a href=cxx-closed.html#A5>A-5</a>.
Closed <a href=cxx-closed.html#A30>A-30</a>,
<a href=cxx-closed.html#A31>A-31</a>,
<a href=cxx-closed.html#D14>D-14</a>,
<a href=cxx-closed.html#D18>D-18</a>,
<a href=cxx-closed.html#G4>G-4</a>.


<p>
<font color=blue>[001107]</font>
New issues <a href=#A30>A-30</a>, <a href=#A31>A-31</a>.
<a href=#D18>D-18</a>.

<p>
<font color=blue>[000901]</font>
Closed <a href=cxx-closed.html#C19>C-19</a>.

<p>
<a href=#ancient>Ancient revision history</a>.


<p> <hr> <p>
<h3> Definitions </h3>

<p>
The issues below make use of the following definitions:

<dl>

<p>
<dt> <i>dynamic class</i> </dt>
<dd>
A class that requires a virtual pointer,
due to either virtual functions or virtual bases.

<p>
<dt> <i>empty class</i> </dt>
<dd>
A class with no non-static data members other than zero-width bitfields,
no virtual functions, no virtual base classes,
and no non-empty non-virtual base classes.

<p>
<dt> <i>nearly empty class</i> </dt>
<dd>
A class that:
<ul>
<li> has no non-static data members other than zero-width bitfields,
<li> has no base classes that are not either empty or nearly empty,
<li> has at most one nearly empty base class, and
<li> has at least one virtual function, possibly inherited from a base class.
</ul>
Such a class contains only a Vptr.

<p>
<dt> <i>vague linkage</i> </dt>
<dd>
The treatment of entities --
e.g. inline functions, templates, vtables --
with external linkage that can be
defined in multiple translation units,
while the ODR requires that the program
behave as if there were only a single definition.

</dl>


<p> <hr> <p>
<h3> Issue Status </h3>

In the following sections,
the <b><i>class</i></b> of an issue attempts to classify it on the
basis of what it likely affects.
The identifiers used are:

<table>
<tr> <td> call </td>
<td> Function call interface, i.e. call linkage </td>
</tr>

<tr> <td> data </td>
<td> Data layout </td>
</tr>

<tr> <td> lib </td>
<td> Runtime library support </td>
</tr>

<tr> <td> lif </td>
<td> Library interface, i.e. API </td>
</tr>

<tr> <td> g </td>
<td> Potential gABI impact </td>
</tr>

<tr> <td> ps </td>
<td> Potential psABI impact </td>
</tr>

<tr> <td> source </td>
<td> Source code conventions (i.e. API, not ABI) </td>
</tr>

<tr> <td> tools </td>
<td> May affect how program construction tools interact </td>
</tr>
</table>

<p> <hr> <p>
<h3> Object Layout Issues </h3>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=A1></a> <td> A-1 </td>
<td> Vptr location </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 990624 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Where is the Vptr stored in an object (first or last are the usual answers).
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A1> Resolution </a></b>:
First.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=A2></a> <td> A-2 </td>
<td> Virtual base classes </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 990624 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Where are the virtual base subobjects placed in the class layout?
How are data member accesses to them handled?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A2> Resolution </a></b>:
Virtual base subobjects are normally placed at the end (see issue A-9).
The Vtable will contain an offset to the beginning of the base object
for use by member accesses to them (see issue B-6).
</td> </tr>

</table>

<p>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <td> A-3 </td>
<td> Multiple inheritance </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 990701 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define the class layout in the presence of multiple base classes.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A3> Resolution </a></b>:
See the class layout description in closed issue A-9.
Briefly, empty bases will normally go at offset zero,
non-virtual base classes at the beginning,
and virtual base classes at the end.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <td> A-4 </td>
<td> Empty base classes </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 990624 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Where are empty base classes allocated?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A4> Resolution </a></b>:
At offset zero if possible.  See A-9.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A5></a> <td> A-5 </td>
<td> Empty parameters </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 001117 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
When passing a parameter with an empty class type by value,
what is the convention?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A5> Resolution </a></b>:
Except for cases of non-trivial copy constructors (see C-7),
and parameters in the variable part of varargs lists,
A single parameter slot will be allocated to empty parameters,
as though they were a struct containing a single character.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=A6></a> <td> A-6 </td>
<td> RTTI .o representation </td>
<td> data call ps </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 991028 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define the data structure to be used for RTTI, that is:
<ul>
<li> for user <code>type_info</code> calls;
<li> for dynamic_cast implementation; and
<li> for exception-handling.
</ul>
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A6> Resolution </a></b>:
Defined in the
<a href=abi.html#rtti>Draft C++ ABI for IA-64 </a> document.
</tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <td> A-7 </td>
<td> Vptr sharing with primary base class </td>
<td> data </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 990729 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
It is in general possible to share the virtual pointer with a
dynamic base class (the <i>primary</i> base class).
Which base class do we use for this?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A7> Resolution </a></b>:
Share with the first non-virtual dynamic base class,
or if none with the first nearly empty virtual base class.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <td> A-8 </td>
<td> (Virtual) base class alignment </td>
<td> data </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 990624 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
A (virtual) base class may have a larger alignment constraint than a
derived class.
Do we agree to extend the alignment constraint to the derived class?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A8> Resolution </a></b>:
The derived class will have at least the alignment of any base class.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <td> A-9 </td>
<td> Sorting fields as allowed by [class.mem]/12 </td>
<td> data </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 990624 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The standard constrains ordering of class members in memory only if
they are not separated by an access clause.
Do we use an access clause as an opportunity to fill the gaps left by padding?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A9> Resolution </a></b>:
See the
<a href=abi.html#class-types>Draft C++ ABI for IA-64 </a>.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <td> A-10 </td>
<td> Class parameters in registers </td>
<td> call </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 990701 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The C ABI specifies that small structs are passed in registers.
Does this apply to small non-POD C++ objects passed by value?
What about the copy constructor and <code>this</code> pointer in that case?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A10> Resolution </a></b>:
Non-POD C++ objects are passed like C structs,
except for cases with non-trivial copy constructors identified in C-7.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=A11></a> <td> A-11 </td>
<td> Pointers to member functions </td>
<td> data </td>
<td> closed </td>
<td> Cygnus </td>
<td> 990603 </td>
<td> 990812 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How should pointers to member functions be represented?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A11> Resolution</a></b>:
As a pair of values, a "pointer" and a this adjustment.
See the closed list for a more detailed description.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=A12></a> <td> A-12 </td>
<td> Merging secondary vtables </td>
<td> data </td>
<td> closed </td>
<td> Sun </td>
<td> 990610 </td>
<td> 990805 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Sun merges the secondary Vtables for a class (i.e. those for
non-primary base classes) with the primary Vtable by appending them.
This allows their reference via the primary Vtable entry symbol,
minimizing the number of external symbols required in linking,
in the GOT, etc.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A12> Resolution</a></b>:
Concatenate the Vtables associated with a class in the same order
that the corresponding base subobjects are allocated in the object.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <td> A-13 </td>
<td> Parameter struct field promotion </td>
<td> call </td>
<td> closed </td>
<td> SGI </td>
<td> 990603 </td>
<td> 990701 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
It is possible to pass small classes either as memory images,
as is specified by the base ABI for C structs,
or as a sequence of parameters, one for each member.
Which should be done, and if the latter,
what are the rules for identifying "small" classes?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A13> Resolution</a></b>:
No special treatment will be specified by the ABI.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A14></a> <td> A-14 </td>
<td> Pointers to data members </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 990729 </td>
<td> 990805 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How should pointers to data members be represented?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A14> Resolution</a></b>:
Represented as one plus the offset from the base address.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A15></a> <td> A-15 </td>
<td> Empty bit-fields </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 991214 </td>
<td> 000106 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How are zero-length bit-fields handled?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A15> Resolution</a></b>:
Zero-length bit-fields do not prevent a class from being considered
empty or nearly empty.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A16></a> <td> A-16 </td>
<td> Nearly empty virtual bases </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 991228 </td>
<td> 000106 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
May a class with non-empty, non-primary, virtual base classes
be treated as nearly empty (and thus eligible to be a primary base)
if its only non-vptr data is in its virtual base classes?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A16> Resolution</a></b>:
Virtual base classes do not prevent a class from being considered
nearly empty.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A17></a> <td> A-17 </td>
<td> Primary indirect virtual base allocation </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 991228 </td>
<td> 000113 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
When a nearly empty virtual base class A is allocated as the primary
base class of class B, and then B is allocated as a base class of C,
should A (i.e. its vptr) be separately allocated in C,
or should its first occurrence in a previously allocated base B be used
as its allocation in C?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A17> Resolution</a></b>:
Do not reallocate a nearly empty virtual base class that is the primary
base class of any other base class, direct or indirect.
Use the first primary base class instance in the inheritance hierarchy
as its allocation, in the usual depth-first, left-to-right order.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A18></a> <td> A-18 </td>
<td> Virtual base alignment </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 991228 </td>
<td> 000113 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Should virtual bases have a different effect on class alignment than
other components?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A18> Resolution</a></b>:
Yes.  When allocating the non-virtual part of a base class,
use its <i>non-virtual</i> allignment,
i.e. ignoring its virtual bases' contributions.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A19></a> <td> A-19 </td>
<td> Primary indirect virtual base choice </td>
<td> data </td>
<td> closed </td>
<td> All </td>
<td> 000106 </td>
<td> 000120 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
In allocating class C,
when the first nearly empty virtual base class A is allocated as the
primary base class of a later nearly empty virtual base class B,
should A or B become the primary base class of C?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A19> Resolution</a></b>:
Do not use a virtual base as primary if it is already a primary base of
some other direct or indirect base,
unless such are the only candidates.
In either case, use the first candidate in depth-first, left-to-right
order in the inheritance graph.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A20></a> <td> A-20 </td>
<td> Operator new array cookies </td>
<td> data </td>
<td> closed </td>
<td> All </td>
<td> 000113 </td>
<td> 000120 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
When operator new is used to create a new dynamic-length array,
a cookie must be stored to remember the allocated length
so that it can be deallocated correctly.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A20> Resolution</a></b>:
In principle, place cookie immediately before array, aligned naturally.
Use no cookie for element types with no destructors.
See the <a href=abi.html#array-new> Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A21></a> <td> A-21 </td>
<td> Placement new array cookies </td>
<td> data </td>
<td> closed </td>
<td> All </td>
<td> 000113 </td>
<td> 000217 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Same issue as A-20, except that for placement new,
the user supplies already-allocated space.
Therefore, there is a conflict between wanting to make delete()
work on arrays created in this way,
and wanting to avoid surprising users who haven't allocated enough
space for the cookie.
Also, are cookies allocated if there is no destructor?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A21> Resolution</a></b>:
Use no cookie for element types with no destructors,
nor for <code>::operator new(size_t, void*)</code>.
Otherwise, use a cookie as in issue A-20.
See the <a href=abi.html#array-new>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A22></a> <td> A-22 </td>
<td> RTTI for reference types </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000119 </td>
<td> 000203 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
__reference_type_info does not appear to be necessary.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A22> Resolution</a></b>:
Remove it.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A23></a> <td> A-23 </td>
<td> RTTI class descriptors </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000124 </td>
<td> 000302 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Resolve several questions about the RTTI representation of class types.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A23> Resolution</a></b>:
See the <a href=abi.html>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A24></a> <td> A-24 </td>
<td> RTTI for incomplete types </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000126 </td>
<td> 000330 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How does RTTI represent incomplete types?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A24> Resolution</a></b>:
Use class_type_info distinct from the complete type copy,
add a flag to pointer_type_info if it points to incomplete type RTTI,
and do mangled name comparison if an incomplete pointer is involved.
See the writeup in the 
<a href=abi.html#rtti>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A25></a> <td> A-25 </td>
<td> Excess-width bitfields </td>
<td> data </td>
<td> closed </td>
<td> IBM </td>
<td> 000204 </td>
<td> 000217 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
C++ allows bitfields with a larger size specified than that required by
the declared type, e.g. <code>int f: 64</code>.
How should they be allocated?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A25> Resolution</a></b>:
Allocate the field with alignment determined as though it were the
largest integer type that fits in the specified size,
and use the first bits available in the field
(lowest order for little endian IA-64)
for the actual data.
</td> </tr>

</table> 


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A26></a> <td> A-26 </td>
<td> NULL pointers to member functions </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000221 </td>
<td> 000302 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How are NULL pointers to member functions represented?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A26> Resolution</a></b>:
A NULL pointer is represented by a 0 value of <code>ptr</code>,
and the value of <code>adj</code> is irrelevant.
</td> </tr>

</table> 


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A27></a> <td> A-27 </td>
<td> NULL pointers to data members </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000222 </td>
<td> 000302 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How are NULL pointers to member data represented?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A27> Resolution</a></b>:
A NULL pointer is represented by the value -1.
</td> </tr>

</table> 


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A28></a> <td> A-28 </td>
<td> RTTI equality testing </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000406 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Can we get back the ability to do a simple test for RTTI equality?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A28> Resolution</a></b>:
Mangle the name NTBS for std::type_info separately,
emit it in its own COMDAT,
and use it instead of the RTTI struct,
at least if the incomplete flags are set in pointer types.
</td> </tr>

</table> 


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>


<tr class=small> <a name=A29></a> <td> A-29 </td>
<td> RTTI pointer-to-member </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000407 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Derive __pointer_to_member_type_info from __pointer_type_info.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A29> Resolution</a></b>:
Derive __pointer_to_member_type_info and __pointer_type_info from
a common base class __pbase_type_info.
Add a new flag to __pbase_type_info indicating that the class of a
pointer-to-member is incomplete
(propagated up a chain of pointers).
</td> </tr>

</table> 


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A30></a> <td> A-30 </td>
<td> RTTI portability </td>
<td> data </td>
<td> closed </td>
<td> HUB </td>
<td> 001012 </td>
<td> 001109 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
What must be specified to produce RTTI portability?
Are member layouts specified?  Names?  Virtual functions?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A30> Resolution</a></b>:
Data members of the ABI-defined type_info derived classes must be
allocated as specified, and their names are normative.
Virtual functions, beyond the Standard-specified destructor,
are implementation-specific,
and may not be referenced outside the compiler and system vendors'
runtime libraries.
</td> </tr>
</table> 


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=A31></a> <td> A-31 </td>
<td> Overlaying tail padding </td>
<td> data </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 001019 </td>
<td> 001109 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Should we change the decision to overlay tail padding in class layout?
For volatile members?  In general?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#A31> Resolution</a></b>:
The overlaying of tail padding is eliminated,
but we will retain the treatment of empty bases.
</td> </tr>
</table> 


<p> <hr> <p>
<h3> Virtual Function Handling Issues </h3>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B1></a> <td> B-1 </td>
<td> Adjustment of "this" pointer (e.g. thunks) </td>
<td> data call </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 991202 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
There are several methods for adjusting the <i>this</i> pointer
for a member function call,
including thunks or offsets located in the vtable.
We need to agree on the mechanism used,
and on the location of offsets, if any are needed.
To maximize performance on IA64,
a slightly unusual approach such as using secondary entry points
to perform the adjustment may actually prove interesting. 
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B1> Resolution</a></b>:
See the writeup in the
<a href=abi.html#vcall>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B2></a> <td> B-2 </td>
<td> Covariant return types </td>
<td> call </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 990722 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
There are several methods for adjusting the 'this' pointer of the
returned value for member functions with covariant return types.
We need to decide how this is done.
Return thunks might be especially costly on IA64,
so a solution based on returning multiple pointers may prove more interesting.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B2> Resolution</a></b>:
Provide a separate Vtable entry for each return type.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B3></a> <td> B-3 </td>
<td> Allowed caching of vtable contents </td>
<td> call </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 990805 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The contents of the vtable can sometimes be modified,
but the concensus is that it is nonetheless always allowed to "cache" elements,
i.e. to retain them in registers and reuse them,
whenever it is really useful.
However, this may sometimes break "beyond the standard" code,
such as code loading a shared library that replaces a virtual function.
Can we all agree when caching is allowed? 
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B3> Resolution</a></b>:
Caching is allowed within a member function.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B4></a> <td> B-4 </td>
<td> Function descriptors in vtable </td>
<td> data </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 990805 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
For a runtime architecture where the caller is expected to load the GP
of the callee (if it is in, or may be in, a different DSO), e.g. HP/UX,
what should vtable entries contain?
One possibility is to put a function address/GP pair in the vtable.
Another is to include only the address of a thunk which loads the GP
before doing the actual call.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B4> Resolution</a></b>:
The Vtable will contain a function address/GP pair.
</td> </tr>

</table>

<p>
<font color=blue>[991007 All]</font>
Note that, though this issue was closed,
it may prove necessary to reopen it if the underlying C ABI treatment
of function pointers changes.


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B5></a> <td> B-5 </td>
<td> Where are vtables emitted? </td>
<td> data </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 991118 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
In C++, there are various things with external linkage that can be
defined in multiple translation units,
while the ODR requires that the program
behave as if there were only a single definition.
From the user's standpoint, this applies to inlines and templates.
From the implementation's perspective,
it also applies to things like vtables and RTTI info.
(We call this <i>vague linkage</i>.)
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B5> Resolution</a></b>:
Vtables will be emitted with the key function (first virtual function
that is not inline at the point of class definition), if any.
If no key function, emit everywhere used (i.e. referred to by name).
Place in a comdat group in all cases.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B6></a> <td> B-6 </td>
<td> Virtual function table layout </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 991028 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
What is the layout of the Vtable?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B6> Resolution</a></b>:
See the 
<a href=abi.html#vtable>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B7></a> <td> B-7 </td>
<td> Objects and Vtables in shared memory </td>
<td> data </td>
<td> closed </td>
<td> HP </td>
<td> 990624 </td>
<td> 990805 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Is it possible to allocate objects in shared memory?
For dynamic objects, this implies that the Vtable must also be
in shared memory.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B7> Resolution</a></b>:
No special representation is useful in support of shared memory.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B8></a> <td> B-8 </td>
<td> dynamic_cast </td>
<td> data </td>
<td> closed </td>
<td> SGI </td>
<td> 990628 </td>
<td> 991014 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
What information to we put in the vtable to enable (a) dynamic_cast
from pointer-to-base to pointer-to-derived (including detection of
ambiguous base classes) and (b) dynamic_cast to void*?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B8> Resolution</a></b>:
The vtable will contain an offset to the beginning of the complete object,
and a pointer to the typeinfo object.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=B9></a> <td> B-9 </td>
<td> Primary base vtable embedding </td>
<td> data </td>
<td> closed </td>
<td> Cygnus </td>
<td> 000217 </td>
<td> 000302 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Resolve the embedding of the vtable for the primary base class
in the derived class vtable.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B9> Resolution</a></b>:
Any class with virtual bases shall contain vbase pointers
for all of its virtual bases.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a href=cxx-closed.html#B10> <td> B-10 </td></a>
<td> Pure virtual runtime </td>
<td> call </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000629 </td>
<td> 000706 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define a runtime proxy routine for pure virtual functions.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#B10> Resolution</a></b>:
Define such a runtime routine, with implementation-defined behavior.
</td> </tr>

</table>


<p> <hr> <p>
<h3> Object Construction/Destruction Issues </h3>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C1></a> <td> C-1 </td>
<td> Interaction with .init/.fini </td>
<td> lif ps </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 991202 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Static objects with dynamic constructors must be constructed at
intialization time.
This is done via the executable object initialization functions that
are identified (in ELF) by the DT_INIT and DT_INIT_ARRAY dynamic tags.
How should the compiler identify the constructors to be called in this way?
One traditional mechanism is to put calls in a .init section.
Another, used by HP, is to put function addresses in a .init_array section.
<p>
The dual question arises for static object destructors.
Again, the extant mechanisms include putting calls in a .fini section,
or putting function addresses in a .fini_array section.
<p>
Finally, which mechanism (DT_INIT or DT_INIT_ARRAY, or the FINI versions)
should be used in linked objects?
The gABI, and the IA-64 psABI, will support both,
with DT_INIT being executed before the DT_INIT_ARRAY elements.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C1> Resolution</a></b>:
Use .init_array and .fini_array sections.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C2></a> <td> C-2 </td>
<td> Order of ctors/dtors w.r.t. link </td>
<td> lif ps </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 000817 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Given that the compiler has identified constructor/destructor calls for
static objects in each relocatable object, in what order should the
static linker combine them in the linked executable object?
(The initialization order determines the finalization order,
as its opposite.)
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C2> Resolution</a></b>:
Accepted method based on IBM's specification.
See <a href=abi.html#ctor-order>Draft C++ ABI for IA-64</a>, Section 3.3.4.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C3></a> <td> C-3 </td>
<td> Order of ctors/dtors w.r.t. DSOs </td>
<td> ps </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Given the constructor/destructor calls for each executable object
comprising a program, what is the order of execution between objects?
For constructors, there is not much question:
unless we choose some explicit means of control,
file-scope objects will be initialized by the DT_INIT/DT_INITARRAY
functions in the order determined by the base ABI order rules,
and local objects will be initialized in the order their containing
scopes are entered.
<p>
For destructors, the Standard requires opposite-order destruction,
which implies a runtime structure to keep track of the order.
Furthermore, the potential for dynamic unloading of a DSO
(e.g. by dlclose)
requires a mechanism for early destruction of a subset.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C3> Resolution</a></b>:
Accept SGI proposal for a simple API which registers destructors and
atexit calls.
Subsequently, accept proposal to eliminate call to __cxa_finalize when
program exits.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C4></a> <td> C-4 </td>
<td> Construction vtables </td>
<td> call </td>
<td> closed </td>
<td> Cygnus </td>
<td> 990603 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
When calling a virtual function from the constructor/destructor of a
base subobject,
the version specific to the base type is required,
unlike the typical case when calling such a vfunc for the full object
from some other context.
Since the pointer for that vfunc in the the subobject's sub-vtable
of the full object's vtable is the full object version,
some other means is required for accessing the correct vfunc.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C4> Resolution</a></b>:
Accept Compaq proposal as currently documented in the
<a href=abi.html#rtti>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C5></a> <td> C-5 </td>
<td> Calling destructors </td>
<td> call </td>
<td> closed </td>
<td> Sun </td>
<td> 990603 </td>
<td> 991104 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
What is the calling convention for destructors?
Do virtual destructors require special treatment?
Is delete() integrated with the destructor call or separate?
How is delete() handled when invoked on a base subobject?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C5> Resolution</a></b>:
Destructors are called with a reference to <i>this</i>.
Virtual destructors have two versions, and two entries in the vtable,
one that deletes the object after destruction, and one that doesn't.
There is a third version that does not delete the object,
and is not in-charge, i.e. does not destroy any base objects;
it is not called via the vtable.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C6></a> <td> C-6 </td>
<td> Extra parameters to constructors </td>
<td> call </td>
<td> closed </td>
<td> Cygnus </td>
<td> 990603 </td>
<td> 991104 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
When calling constructors for classes with virtual bases,
what information about the treatment of virtual base subobjects
in the full class, or about object allocation,
must be transmitted to the constructor in parameters?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C6> Resolution</a></b>:
None.
Two versions, and two entrypoints,
of the constructor will be created:
one that calls the virtual base subobject constructor (in-charge),
and one that does not.
Object allocation will be done by the caller.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C7></a> <td> C-7 </td>
<td> Passing value parameters by reference </td>
<td> call </td>
<td> closed </td>
<td> All </td>
<td> 990624 </td>
<td> 990805 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
It may be desirable in some cases where a type has a non-trivial
copy constructor to pass value parameters of that type by performing
the copy at the call site and passing a reference.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C7> Resolution</a></b>:
Whenever a class type has a non-trivial copy constructor,
pass value parameters of that type by performing
the copy at the call site and passing a reference.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C8></a> <td> C-8 </td>
<td> Returning classes with non-trival copy constructors </td>
<td> call </td>
<td> closed </td>
<td> All </td>
<td> 990625 </td>
<td> 990722 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How do we return classes with non-trivial copy constructors?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C8> Resolution</a></b>:
The caller allocates space,
and passes a pointer as an implicit first parameter
(prior to the implicit <i>this</i> parameter).
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C9></a> <td> C-9 </td>
<td> Passing parameters with ctors/dtors </td>
<td> call </td>
<td> closed </td>
<td> All </td>
<td> 991028 </td>
<td> 991104 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Where do allocation, construction, destruction, and deallocation occur
for value parameters?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C9> Resolution</a></b>:
<a href=cxx-closed.html#C9>closed issues list</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C10></a> <td> C-10 </td>
<td> Synthesized copy assignments </td>
<td> call </td>
<td> closed </td>
<td> All </td>
<td> 991028 </td>
<td> 991028 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Should we specify special treatment for synthesized copy assignments,
to avoid multiple copies of virtual bases?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C10> Resolution</a></b>:
No.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C11></a> <td> C-11 </td>
<td> Array constructors/destructors </td>
<td> call </td>
<td> closed </td>
<td> Cygnus </td>
<td> 000130 </td>
<td> 000309 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How are constructors/destructors run for arrays?
Many compilers use a <code>__vec_new</code> function;
g++ doesn't, to allow for inlining of constructors.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C11> Resolution</a></b>:
Define standard library entries for array construction/destruction.
See the <a href=abi.html#array-ctor>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C12></a> <td> C-12 </td>
<td> Constructor return values </td>
<td> call </td>
<td> closed </td>
<td> Cygnus </td>
<td> 000130 </td>
<td> 000309 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
What is the return value of a constructor?
Void, this, ...?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C12> Resolution</a></b>:
Void.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C13></a> <td> C-13 </td>
<td> Allocating constructors </td>
<td> call </td>
<td> closed </td>
<td> HP </td>
<td> 000309 </td>
<td> 000803 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Should we define allocating constructors?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C13> Resolution</a></b>:
Their use is optional.
Their name mangling is specified.
If used, they must be emitted everywhere referenced as a COMDAT group
(Draft ABI section 5.2.5).
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C14></a> <td> C-14 </td>
<td> Local-scope dynamic constructors </td>
<td> data </td>
<td> closed </td>
<td> all </td>
<td> 000309 </td>
<td> 000511 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The Standard requires that local static objects with dynamic
constructors be initialized exactly once,
the first time the containing scope is entered.
This requires a data object to serve as a guard variable;
define its content or interface.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C14> Resolution</a></b>:
The size of the guard variable is 64 bits.
The low-order byte shall contains a boolean initialization flag.
</td> </tr>

</table>


<p> <a name=C15></a>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a href=cxx-closed.html#C15> <td> C-15 </td></a>
<td> Alternate array allocators </td>
<td> call </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000628 </td>
<td> 000720 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Allow alternate allocators/deallocators to
<code>__cxa_vec_new</code> and <code>__cxa_vec_delete</code>.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C15> Resolution</a></b>:
Add two new allocators, and two new deallocators,
with one of each pair using a simple user deallocator
and one using a user deallocator requiring a size.
See the <a href=abi.html#array-ctor>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p> <a name=C16></a>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a href=cxx-closed.html#C16> <td> C-16 </td></a>
<td> Copy constructor runtime </td>
<td> call </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000628 </td>
<td> 000720 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define a runtime support routine for copy constructors.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C16> Resolution</a></b>:
Add a new runtime for vector copy construction.
See the <a href=abi.html#array-copy-ctor>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p> <a name=C17></a>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a href=cxx-open.html#C17> <td> C-17 </td></a>
<td> Uncatch exception runtime </td>
<td> call </td>
<td> tabled </td>
<td> all </td>
<td> 000706 </td>
<td> 000720 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define a runtime support routine to uncatch the current exception.
</td> </tr>
<!--
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C17> Resolution</a></b>:
See the <a href=abi.html#array-copy-ctor>Draft C++ ABI for IA-64</a>.
</td> </tr>
-->

</table>

<p>
<font color=blue>[000706 All]</font>
This comes up in the context of the sample code in C-16,
i.e. the call to g++'s routine __uncatch_exception(),
which backs out the current exception so that another one won't cause
termination.
This is possible with the current APIs,
but a single call is simpler,
will appear in various contexts,
and is not performance sensitive, so needn't be an inline sequence.

<p>
<font color=blue>[000720 All]</font>
We believe that all calls to this functionality come from the
implementation runtime rather than from the compiled code,
so the interface does not need to be exposed.
The issue is tabled unless and until someone determines otherwise.


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C18></a> <td> C-18 </td>
<td> Result buffers </td>
<td> call </td>
<td> closed </td>
<td> SGI </td>
<td> 000724 </td>
<td> 000817 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Should buffers for results with non-trivial copy constructors be passed
as a dummy first parameter, or in r8 as specified by the psABI for long
structured results?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C18> Resolution</a></b>:
All results with non-trivial copy constructors or destructors will be
returned in buffers allocated by the caller,
with their addresses passed as an implicit first parameter.
Other structure results too large for the return registers are
returned in a buffer created by the caller,
with the buffer address passed in r8.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=C19></a> <td> C-19 </td>
<td> NULL ctor/dtor API parameters </td>
<td> call </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000806 </td>
<td> 000831 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Allow NULL constructor/destructor parameters whereever it makes sense
in the Section 3.3 APIs.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#C19> Resolution</a></b>:
Accepted as proposed.
</td> </tr>

</table>


<p> <hr> <p> <a name=Dstart></a>
<h3> Exception Handling Issues </h3>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D0></a> <td> D-0 </td>
<td> Exception handling framework </td>
<td> lib ps </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 991216 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define the general framework for exception handling,
including Level I (psABI unwinding API)
and Level II (C++ ABI exception handling API).
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D0> Resolution</a></b>:
See the <a href=exceptions.pdf> HP proposal</a>,
accepted as a working paper,
and discussions in the closed issues page.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D1></a> <td> D-1 </td>
<td> Language-specific data area format </td>
<td> lib ps </td>
<td> open </td>
<td> SGI </td>
<td> 990520 </td>
<td> </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The IA-64 runtime conventions describe language-independent descriptors
for restoring registers when unwinding the stack.
The do not specify how C++ performs language-specific unwinding for
exception handling, i.e. locating a handler and destroying automatic
objects.
Note that this can be handled by agreeing on common descriptors,
or by agreeing on per-frame personality routines with common APIs.
</td> </tr>

</table>

<p>
<font color=blue>[990715 Cygnus -- Jason]</font>
The languge-specific part of the EH stack in g++ contains these
elements:

<p>
<code><pre>
void *value; // pointer to the thrown object, or the thrown value
             // itself if a pointer
void *type;  // pointer to the type_info node for the thrown object
void (*cleanup)(void *, int) // pointer to the dtor for the object
bool caught; // has this exception been caught since its last throw?
long handlers; // how many catch handlers are active for this exception
</code></pre>

<p>
Both 'caught' and 'handlers' are needed to handle rethrowing and
catching within a catch block.

<p>
Language interaction is handled by recording the language of both the
exception region and the thrown exception.  Each thrown exception also
includes a pointer to a language-specific matching function which is
called to compare the types of the exception and handler.

<p>
<font color=blue>[991209 all]</font>
Observe that this issue is part of a
<a href=#exception-level3>level 3 specification</a>,
i.e. part of a common runtime specification,
but not strictly part of the ABI.
It is described as part of the
<a href=http://www.codesourcery.com/cxx-abi/exceptions.pdf>
EH working paper</a> from HP.

<p>
<font color=blue>[991216 all]</font>
The <code>__typeinfo</code> type defined in 7.6 of the working paper
should be replaced by the ABI standard <code>type_info</code>.
The treatment of predefined types must be specified.

<p>
<font color=blue>[000126 editor]</font>
This issue is effectively closed by virtue of accepting the working
paper (D-0),
but I will not close it officially until the
<a href=exceptions.pdf>working paper</a>
reflects the <code>__typeinfo</code> change.


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D2></a> <td> D-2 </td>
<td> Unwind personality routines </td>
<td> lib ps </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 000106 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The IA-64 runtime conventions provide for a personality routine
pointer for language-specific actions when unwinding the stack.
They do not specify its interface.
There are typically two required actions for C++:
locating a handler (non-destructively)
and destroying automatic objects while unwinding.
This issue involves specification of the API (see also D-3).
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D2> Resolution</a></b>:
See the <a href=abi-eh.pdf> exception handling specification</a>,
level 1, and the <a href=exceptions.pdf>working paper</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D3></a> <td> D-3 </td>
<td> Unwind process clarification </td>
<td> lib ps </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 000106 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The IA-64 runtime conventions provide for a personality routine
pointer for language-specific actions when unwinding the stack.
However, they are quite muddy about the precise sequence of calls.
This issue involves specification of unwind process (see also D-2).
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D3> Resolution</a></b>:
See the <a href=abi-eh.pdf> exception handling specification</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D4></a> <td> D-4 </td>
<td> Unwind routines nested? </td>
<td> lib ps </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 991209 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The IA-64 runtime conventions call for the unwind personality routine
to behave like a routine nested in the routine raising an exception.
Is that the preferred definition?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D4> Resolution</a></b>:
This is not required, nor included in the proposed common implementation.
However, a conforming implementation could add this option in the
personality routine and tables.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D5></a> <td> D-5 </td>
<td> Interaction with other languages (e.g. Java) </td>
<td> lib ps </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 991007 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The IA64 exceptions handling framework is largely language independent.
What is the behaviour of a C++ runtime receiving, for instance,
an exception thrown from Java?
Does it call terminate()?
Does it allow the exception to pass through C++ code with destructors
if there is no catch clause?
Does it allow the exception to be caught in a catch(...) provided this
catch(...) ends with a rethrow?
Does it allow even more?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D5> Resolution</a></b>:
In general, foreign exceptions will cause normal destructor invocation
and other cleanup in C++ code, and will pass through C++ frames except
where explicit exception specifications do not allow them.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D6></a> <td> D-6 </td>
<td> Allow resumption in other languages? </td>
<td> lib ps </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 991007 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The exception handling framework requires the interaction of the
runtime of all the languages "on the stack" during exception processing.
Some of these languages may have very different exception handling semantics.
What are the constraints we impose on the C++ exception handling runtime
to preserve the relative language neutrality of the EH framework?
Example: do we allow a handler to cleanup and resume at the point
where the exception was thrown?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D6> Resolution</a></b>:
Moot -- resume-type exceptions are more appropriately handled by
registering trap handlers and processing them in place.
No interaction with stack traceback should be necessary.
</td> </tr>

</table>

<p>
<font color=blue>[990908 SGI -- Jim]</font>
The typical case of cleanup and resume is floating point trap handling,
which is normally handled entirely in the original FP trap handler.
Is there an example where stack walkback must occur to identify the
handler, but resumption at the point-of-exception is required?
I can't think of any, and I think the model of registering a trap
handler is preferable for such purposes.

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D7></a> <td> D-7 </td>
<td> Interaction with signals or asynch events </td>
<td> lib ps </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 991209 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The Standard says that the behavior of anything other than
"pure C code" (POF) is implementation defined,
and warns (in a note) against using EH in a signal handler.
We should define what is supported,
possibly explicitly stating that signal handler code must be a POF.
We could allow any feature but exception handling to be used.
We could allow some EH routines to be called
(for instance, <code>uncaught_exception()</code>).
Or we could allow even an exception to be thrown,
if it does not exit the handler.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D7> Resolution</a></b>:
This ABI requires no support beyond the Standard requirements.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D8></a> <td> D-8 </td>
<td> Interaction with threads packages </td>
<td> lib ps </td>
<td> closed </td>
<td> SGI </td>
<td> 990603 </td>
<td> 000106 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
What happens when an exception is not caught in the thread where raised?
What does <code>uncaught_exception()</code>
return if another thread is currently processing an exception?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D8> Resolution</a></b>:
With one exception, exception handling is entirely per-thread --
exceptions must be caught in the thread where raised,
and queries about them (e.g. <code>uncaught_exception()</code>)
are answered only with respect to the thread doing the query.
The only global exception behavior is handler registration --
see <a href=cxx-closed.html#D15>issue D-15</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D9></a> <td> D-9 </td>
<td> longjmp interaction </td>
<td> lib ps </td>
<td> closed </td>
<td> IBM </td>
<td> 990908 </td>
<td> 000113 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Does longjmp run destructors?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D9> Resolution</a></b>:
Define an alternate routine, longjmp_unwind in namespace abi,
defined in new header cxxabi.h,
which always does full cleanup during unwinding.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D10></a> <td> D-10 </td>
<td> psABI proposal </td>
<td> lib ps </td>
<td> closed </td>
<td> all </td>
<td> 991216 </td>
<td> 000120 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Solidify the Level I (psABI) specification and submit it to the base
ABI group.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D10> Resolution</a></b>:
See the <a href=abi-eh.html#forced>exception handling specification</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D11></a> <td> D-11 </td>
<td> pthreads interface </td>
<td> lib ps </td>
<td> closed </td>
<td> all </td>
<td> 991216 </td>
<td> 000203 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Certain pthreads functionality is a prerequisite,
e.g. to acquire thread-local storage.
The ABI should specify the requirements,
along with the expected stub behavior when
the pthreads library is not present.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D11> Resolution</a></b>:
No specification necessary.
This is Level 3 material.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D12></a> <td> D-12 </td>
<td> Table location </td>
<td> lib ps </td>
<td> closed </td>
<td> all </td>
<td> 991216 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Determine constraints on the location of the unwind table
and the unwind information table.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D12> Resolution</a></b>:
The unwind tables must reside in the text segment they describe.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D13></a> <td> D-13 </td>
<td> _Unwind_ForcedUnwind </td>
<td> lib ps </td>
<td> closed </td>
<td> all </td>
<td> 991216 </td>
<td> 000120 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define the interface of _Unwind_ForcedUnwind.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D13> Resolution</a></b>:
See the <a href=abi-eh.html#forced>exception handling specification</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D14></a> <td> D-14 </td>
<td> __cxa_begin/end_catch </td>
<td> lib </td>
<td> closed </td>
<td> all </td>
<td> 991216 </td>
<td> 001109 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define the interfaces of <code>__cxa_begin_catch</code>
and <code>__cxa_end_catch</code>.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D14> Resolution</a></b>:
See the <a href=abi-eh.html#cxx-handler>exception handling specification</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D15></a> <td> D-15 </td>
<td> Terminate handler and threads </td>
<td> lib </td>
<td> closed </td>
<td> all </td>
<td> 991216 </td>
<td> 000106 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define how the terminate and unexpected handler registration
interacts with threads.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D15> Resolution</a></b>:
Handler registration applies to all threads.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D16></a> <td> D-16 </td>
<td> Exception specifications </td>
<td> lib </td>
<td> closed </td>
<td> all </td>
<td> 991216 </td>
<td> 000113 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How is the type list for an exception specification
represented in the action records?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D16> Resolution</a></b>:
As specified in the HP document
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a href=cxx-open.html#D17> <td> D-17 </td></a>
<td> bad_cast, bad_typeid runtime </td>
<td> call </td>
<td> closed </td>
<td> CodeSourcery </td>
<td> 000629 </td>
<td> 000706 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define runtime support routines for throwing bad_cast and bad_typeid
exceptions.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D17> Resolution</a></b>:
Accepted as proposed originally.
See <a href=abi-eh.html#cxx-aux>draft EH Specification</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=D18></a> <td> D-18 </td>
<td> __cxa_throw_type_info </td>
<td> lib </td>
<td> closed </td>
<td> all </td>
<td> 001012 </td>
<td> 001109 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Should we replace the __cxa_throw_type_info pointer in the exception
object by a pair of pointers to a <code>std::type_info</code> and a
destructor?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#D18> Resolution</a></b>:
Make the replacement.
See Sections 2.2.1 and 2.4.3 of the 
See <a href=abi-eh.html#cxx-data>draft EH Specification</a>.
</td> </tr>
</table>


<p> <hr> <p>
<h3> Template Instantiation Model Issues </h3>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>


<tr> </tr>
<tr> <th> E </th>
<th colspan=6> Template Instantiation Model </th>
</tr>

<tr> <a name=E1></a> <td> E-1 </td>
<td> When does instantiation occur? </td>
<td> tools </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 000511 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
There are two principal models for instantiation.
The <i>early instantiation</i> (or Borland) model performs all
instantiation at compile time,
potentially resulting in extra copies which are removed at link time.
The <i>pre-link instantiation</i> model identifies the required
instantiations prior to linking and instantiates them via a special
compile step.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#E1> Resolution</a></b>:
Non-export templates are instantiated where referenced in COMDAT groups.
See the <a href=abi.html#vague-itemplate>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=E2></a> <td> E-2 </td>
<td> Export template model </td>
<td> tools </td>
<td> tabled </td>
<td> SGI </td>
<td> 990520 </td>
<td> </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The Standard specifies a model of template instantiation that does not
require the template definition to be visible at the point of
instantiation.
What is required for ABI support of this?
</td> </tr>

</table>

<p>
<font color=blue><hr><p>[000413 All]</font>
There are as yet no known implementations of this,
which makes ABI standardization problematic.
EDG is perhaps the furthest along.
Ask Daveed about rumoured necessary mangling changes,
and about where virtual/non-virtual member functions must be emitted.

<p>
<font color=blue>[000423 EDG -- Daveed]</font>
I cannot say much yet, since we're still very actively working on this.
There are at least two ABI issues.
First, as you note, the location of template emission
(which is somewhat more flexible with COMDATs).
Second, there is potential for a whole bunch of previously
internally linked items to need to be promoted to external linkage,
while maintaining the general impression of not colliding with
other "static" entities.

<p>
<font color=blue><hr><p>[000511 All]</font>
We will not deal with export templates at this time,
given no existing implementations to serve as models.


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=E3></a> <td> E-3 </td>
<td> Template repository </td>
<td> tools </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 000511 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Independent of the template instantiation model,
we need to make sure that whatever template persistent storage is used
by one vendor does not interact negatively with other vendors' mechanisms.
Issues:
  (1) Avoiding conflict on the name of any repository.
  (2) If .o files are used,
	describe how this information is to be preserved, ignored, etc.
  (3) Evaluate if tools such as make, ld, ar, or others, can
	break because .o files get written at unexpected times.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#E3> Resolution</a></b>:
COMDAT emission and naming for non-export templates is specified in
the <a href=abi.html#vague-itemplate>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p> <hr> <p>
<h3> Name Mangling Issues </h3>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F1></a> <td> F-1 </td>
<td> Mangling convention </td>
<td> call </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 000330 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
What rules shall be used for mangling names,
i.e. for encoding the information other than the source-level object
name necessary to resolve overloading?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F1> Resolution</a></b>:
See the <a href=abi.html#mangling>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F2></a> <td> F-2 </td>
<td> Mangled name size </td>
<td> call g </td>
<td> closed </td>
<td> SGI </td>
<td> 990520 </td>
<td> 000511 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Typical name mangling schemes to date typically begin to produce very
long names.  SGI routinely encounters multi-kilobyte names,
and increasing usage of namespaces and templates will make them worse.
This has a negative impact on object file size, and on linker speed.
<p>
SGI has considered solutions to this problem including modified string
tables and/or symbol tables to eliminate redundancy.
Cygnus, HP, and Sun have also considered or implemented approaches
which at least mitigate it.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F2> Resolution</a></b>:
The current mangling solution is considered an adequate solution to
this problem.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F3></a> <td> F-3 </td>
<td> Consistency checks
</td>
<td> call g </td>
<td> tabled </td>
<td> SGI </td>
<td> 990520 </td>
<td> </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define a mechanism to support consistency checks, e.g. in the linker,
in cases where the Standard forbids inconsistency but does not require
detection.
</td> </tr>

</table>

<p>
<font color=blue>[991028 all]</font>
In a number of cases,
the Standard requires consistent definitions in different places,
even in different files,
but does not require the implementation to detect and report
inconsistency.
With a small amount of extra information,
the linker could often detect and report such inconsistencies.
Also, there are cases where the linker can already detect a problem,
but could provide a better diagnostic with more information.

<p>
Several examples are:

<ol>
<p>
<li>
A template instantiation may conflict with a full specialization
(in different translation units).

<p>
<li>
Functions may be declared with different throw specifications.

<p>
<li>
Functions may be declared with different return types.

<p>
<li>
Template formal parameter names would help improve instantiation error
messages.

</ol>

<p>
<font color=blue>[000406 all]</font>
<ol>
<li> Instantiation vs. specialization is tabled pending a specific proposal.
<li> Function throw specifications are issue F-4.
<li> Function return types are issue F-10.
<li> There is resistance to doing something with formal parameter names.
    Someone will hunt up John Spicer's commentary on the idea.
</ol>
This issue is reduced to the first example,
and tabled until and unless someone produces a specific proposal.

<p>
<font color=blue><hr><p>[000417 Compaq -- Coleen]</font>
I propose that partial specializations should be mangled differently
than template instantiations.  The reasons:

<ol>
<p>
<li>
It's the standard.  14.5.4 pp 3:

<block>
<p>
Each class template partial specialization is a distinct template
and definitions shall be provided for the members of a
template partial specialization (temp.class.spec.mfunc). 

<p>
Note that the end of paragraph 1 in this section says
"no diagnostic is required",
but does that mean if a template instantiation can be linked
instead of a specialization and not violate the standard?
Or does that only mean that the compiler/linker is not required
to diagnose the error and can call the wrong version of the function?
</block>

<p>
<li>
Since this is a new ABI, users must recompile.
The correction to this problem is a source line change to declare
the specialization.
We should strive to be 100% standard-compliant with the new ABI,
especially with a case we can diagnose.
Users should expect the new ABI to be 100% compliant as well.
</ol>

<p>
The argument against making partial instantiations link incompatible with
is that users may depend on linking in the template instantiation when
the definition of partial instantiation is not available.
Two points:

<ol>
<p>
<li>
With the COMDAT model,
if the partial instantiation is available in one compilation unit
and the template instantiation comes from another,
which will be picked?
Isn't this really bad?

<p>
<li>
As a data point, DEC/Compaq changed the mangling for partial
specializations when using the new syntax (template <>)
but kept the mangling for them the same when using the old
non-standard syntax (omit the template <>).
We don't have any entries about it in our database of complaints.
(We realize more code is written for Sun, HP, g++, etc,
so you may end up with complaints on code our compiler hasn't seen.)
</ol>
 
So I propose a mangling qualifier for partial specializations on each
template argument that is specialized (maybe you don't need the 'E'):
<code><pre>
    &lt;template-args> ::= I &lt;template-arg>+ E
    &lt;template-arg> ::= &lt;type>                     # type
    &lt;template-arg> ::= D &lt;type> E                 # partially specialize'D'
    &lt;template-arg> ::= L &lt;type> &lt;value number> E  # literal
    &lt;template-arg> ::= LZ &lt;encoding> E            # external name
    &lt;template-arg> ::= X &lt;expression> E           # expression
</pre></code>

<code><pre>
//
// Example of partial specialization [not] linking against template
// instantiation.
// 
// spec.h 
extern "C" int printf(const char *,...);
template &lt;class T> class X {
   public:
   void f(); // { printf("X&lt;T>::f called\n"); }
};
// spec1.cxx

#include "spec.h"
main()
{
  X&lt;int> t;
  t.f();
}
// spec2.cxx
#include "spec.h"
template &lt;> class X&lt;int> {
   public:
   void f();
};
template &lt;> void X&lt;int>::f() { printf("X&lt;int>::f();\n"); }

void foo()
{
   X&lt;int> x;
   x.f();
}

//
// EDG/Compaq C++
% exx spec1.cxx spec2.cxx
spec1.cxx:
spec2.cxx:
ld:
Unresolved:
X&lt;int>::f(void)

//
// Sun
33% CC spec1.cxx spec2.cxx
spec1.cxx:
spec2.cxx:
34% a.out
X&lt;int>::f();

// G++
781% g++ spec1.cxx spec2.cxx
782% a.out
X&lt;int>::f();
</pre></code>


<p>
<font color=blue><hr><p>[000417 CodeSourcery -- Mark]</font>
I'm not persuaded that we should mangle specializations and
instantiations differently.  If I understand Colleen's proposal, these
two functions:

<code><pre>
  template &lt;class T> void f(T);
  template &lt;> void f&lt;int>(int) { }

</pre></code>
and

<code><pre>
  template &lt;class T> void f(T) { }
  template void f&lt;int>(int);

</pre></code>

(the first a specialization, the second instantiation),
would be mangled separately.
If I misunderstood, then I apologize,
and only some of it what follows is relevant.

<p>
Here are my objections:

<ul>
<p>
<li>
Real code depends on being able to intermix the two.  In fact,
this is a historical way of putting instantiations in libraries:
you declare a specialization, but then provide an explicit
instantiation in the library.  That prevents clients of the
library from doing implicit instantiations.

<p>
<li>
I don't think the standard doesn't require a diagnostic.

<p>
<li>
There are other wways of getting a diagnostic, if you want one,
other than mangling.  In fact, mangling is probably not likely
to yield useful diagnostics: the message will just be
"xyz undefined", not "you mixed an instantiation and a
specialization".  Other mechanisms could be used for that.
(Analagous here is the ODR: you could mangle into every inline
function its token sequence, and then check the ODR at link-time.
But, you'd be better off to store this on the side.)

<p>
<li>
Real implementations are underway.
We have to start taking making
changes to the draft ABI more seriously.
We're already implementing the ABI in two different compilers,
and I expect others are doing the same.
It's important that we have compilers ready as quickly as possible;
the chip is almost live,
and we don't want there to be a substantial installed base of
non-compliant compilers;
that will substantially reduce the
value of the work this committee has done.
If it ain't broke, we really shouldn't be fixing it now.
</ul>

<p>
<font color=blue><hr><p>[000418 SGI -- John]</font>
I have come to the somewhat reluctant conclusion that attempting
to diagnose this kind of error through name-mangling would be a mistake.
If other ways can be found,
I think they should probably be left to
individual implementations and not made part of the ABI
(but I am less committed to this point:
I have not, however, thought of any promising approach to this).

<ol>
<p>
<li>
If the standard requires no diagnostic for a violation of the rules,
then certainly  a standard-conforming implementation is permitted to
link and execute the program.  (1.4, Paragraph 2).
So this is a quality-of-implementation issue,
not a standard-conformance issue.

<p>
<li>
As Mark points out,
if we use mangling to distinguish specializations from instantiations,
the resulting diagnostics may be hard to interpret.
I regard this as less important, however, than

<p>
<li>
Providing distinct manglings may just allow definitions to coexist
that are  forbidden from doing so.
So it doesn't solve the problem of providing a diagnostic for this error;
it only does so for one flavor of the error.

<p>
<li>
The specific mangling scheme that Colleen proposes does not
distinguish all the necessary variants.
Consider the declarations
<code><pre>
   template &lt;class T> struct X     { void foo();};
   template &lt;class T> struct X&lt;T*> { void foo();};
   template &lt;> struct X&lt;int*>      { void foo();};

</pre></code>
<p>
A program that declares

<code><pre>
  X&lt;int*> x;

</pre></code>

and invokes x.foo()
will thereby reference a function with the signature

<code><pre>
  void X&lt;int*>::foo(void).

</pre></code>

<p>
Three different functions can be invoked,
depending on whether the program includes just the first declaration,
just the first and second,
or the first and third (with or without the second).
Colleen's mangling scheme clearly distinguishes the first and third cases,
but for the second case is forced to pick one of the other two manglings.
It cannot distinguish all three.
</ol>

<p>
<font color=blue><hr><p>[000504 All]</font>
The SGI <a href=prop-F3-interface.html>Interface ELF section specification</a>
is on the web for consideration.
It extends an existing SGI implementation used to catch call interface
mismatches in the linker (i.e. parameter/result types)
to also catch mismatched throw specifications
and instantiation/specialization mismatches.
It works by associating with each call and definition a fairly
compressed descriptor with the necessary information for matching.

<p>
Mark suggested an alternate method which hashes the information to be matched.
He has seen an implementation that used a strong hash that included
everything strictly required to match,
and a weak hash that treated things that would usually work if mixed
the same (e.g. signed/unsigned integers of a particular size).
This has the advantage over the SGI method of being potentially much smaller,
and therefore faster to check.
It has the disadvantage of being less flexible,
since only those combinations of attributes included in the hash can be
checked,
and the checker is not able to provide a specific error message.

<p>
Either approach is implementable as an optional added ELF section,
and objects with the section can be mixed arbitrarily with those without,
causing no problems other than potentially missed checking.
A decision is therefore not urgent,
and we agreed to consider the possibilities over the upcoming break,
and address this issue further in the summer.

<p>
<font color=blue>[000803 all]</font>
There is no current interest in tackling this.  Table the issue.


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F4></a> <td> F-4 </td>
<td> Empty throw specs
</td>
<td> call g </td>
<td> tabled </td>
<td> HP </td>
<td> 990930 </td>
<td> </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
It is useful to be able to identify functions with empty throw specifications,
to allow calling of unexpected() from the runtime during unwinding.
Can this specification be merged into the function's name mangling?
</td> </tr>

</table>

<p>
<font color=blue>[000330 all]</font>
We discussed this subject right after that of mangling the return type
of all functions.
In both cases there is significant concern that we would break enough
"working" but incorrect code to create significant customer problems.
We agreed to think about this issue for a short while (a week or two),
and try to get some data to evaluate the risk,
since doing either of these would also help catch problems.
Jim will also extract the SGI interface specification ELF section,
look at adding throw specifications to it,
and distribute it for consideration.

<p>
<font color=blue><hr><p>[000504 All]</font>
See the comment for issue F-3 above.

<p>
<font color=blue>[000803 all]</font>
There is no current interest in tackling this.  Table the issue.


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F5></a> <td> F-5 </td>
<td> ILP32 vs. LP64
</td>
<td> call </td>
<td> closed </td>
<td> HP </td>
<td> 000210 </td>
<td> 000824 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
This ABI focusses on the LP64 data model.
What should we do (if anything) to support
(a) compatibility between different vendors' ILP32 compilers
(b) compatibility between ILP32 and LP64?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F5> Resolution</a></b>:
Withdrawn -- no action.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F6></a> <td> F-6 </td>
<td> Demangling </td>
<td> lib </td>
<td> closed </td>
<td> Cygnus </td>
<td> 000210 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Users may sometimes want to get demangled names.
Should we provide an entry point for calling a demangler?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F6> Resolution</a></b>:
Provide a simple demangler interface callable from C.
See the <a href=abi.html#demangler>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F7></a> <td> F-7 </td>
<td> Mangling statics </td>
<td> call </td>
<td> closed </td>
<td> HP </td>
<td> 000223 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
What, if anything, should we do about mangling the names of objects in
static functions in case a compiler chooses to inline them?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F7> Resolution</a></b>:
Local objects are mangled with the name of the containing function
followed by a discriminator,
consisting of the object name and possibly a sequence ID.
Strings are mangled with a discriminator consisting of "s" followed
by a sequence ID.
See the <a href=abi.html#mangling-scope>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F8></a> <td> F-8 </td>
<td> Identifiers with unicode letters </td>
<td> call </td>
<td> closed </td>
<td> HU-Berlin </td>
<td> 000323 </td>
<td> 000413 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How should we mangle names containing unicode letters?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F8> Resolution</a></b>:
Follow the underlying C ABI.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=F9></a> <td> F-9 </td>
<td> Strings with unicode letters </td>
<td> call </td>
<td> closed </td>
<td> HU-Berlin </td>
<td> 000323 </td>
<td> 000413 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How should we handle the object file representation of narrow and wide
string literals containing unicode letters?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F9> Resolution</a></b>:
Follow the underlying C ABI.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=F10></a> <td> F-10 </td>
<td> Mangling function return types </td>
<td> call </td>
<td> closed </td>
<td> all </td>
<td> 000330 </td>
<td> 000413 </td>
<td> </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Should we always mangle the return type of a function?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F10> Resolution</a></b>:
No.  It is mangled only for template instantiations/specializations.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=F11></a> <td> F-11 </td>
<td> Hash for local strings </td>
<td> call </td>
<td> closed </td>
<td> all </td>
<td> 000330 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How should we hash strings for local name mangling?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#F11> Resolution</a></b>:
Strings are mangled with a discriminator consisting of "s" followed
by a sequence ID.
See the <a href=abi.html#mangling>Draft C++ ABI for IA-64</a>.
</td> </tr>

</table>


<p> <hr> <p>
<h3> Miscellaneous Issues </h3>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=G1></a> <td> G-1 </td>
<td> Basic command line options </td>
<td> tools </td>
<td> closed </td>
<td> HP </td>
<td> 990603 </td>
<td> 000824 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Can we agree on basic command line options (compiler and linker)
for fundamental functionality,
possibly allowing portable makefiles?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#G1> Resolution</a></b>:
Withdrawn -- no action.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=G2></a> <td> G-2 </td>
<td> Detection of ODR violations </td>
<td> call </td>
<td> closed </td>
<td> Sun </td>
<td> 990603 </td>
<td> 000504 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
[Sun]
(See also F-3.)
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#G2> Resolution</a></b>:
This is a duplicate.
See <a href=#F3>F-3</a>, <a href=#F4>F-4</a>, <a href=#F10>F-10</a>.
</td> </tr>

</table>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=G3></a> <td> G-3 </td>
<td> Inlined routine linkage </td>
<td> call </td>
<td> closed </td>
<td> Sun </td>
<td> 990603 </td>
<td> 991202 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Inline routines with external linkage require a method of handling
vague linkage (see B-5 for definition) for the out-of-line instance,
as well as for any static data they contain.
The latter includes string constants per [7.1.2]/4.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#G3> Resolution</a></b>:
Out-of-line instances are emitted where required,
using COMDAT (issue B-5).
Static data referenced will be placed in COMDAT sections as well.
The names of each are addressed as part of mangling (issue F-1).
Strings will be emitted in SHT_MERGE/SHT_STRING sections,
with the static linker responsible for removing duplicates.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=G4></a> <td> G-4 </td>
<td> Dynamic init of local static objects and multithreading </td>
<td> call </td>
<td> closed </td>
<td> SCO </td>
<td> 990607 </td>
<td> 001109 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The Standard requires that local static objects with dynamic
constructors be initialized exactly once, the first time the containing
scope is entered.
Multi-threading renders the simple check of a flag before
initialization inadequate to prevent multiple initialization.
Should the ABI require locking for this purpose,
and if so, what are the necessary interfaces?
In addition to the locking of the initialization,
special exception handling treatment is required to deal with an
exception during construction.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#G4> Resolution</a></b>:
The ABI will specify an 8-byte guard variable,
with one byte used for the initialization flag,
and the others available for use by a threading package for locking.
ABI routines are specified for acquiring and releasing the lock.
See ABI section 3.3.2.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=G5></a> <td> G-5 </td>
<td> Varargs routine interface </td>
<td> call </td>
<td> closed </td>
<td> HU-B </td>
<td> 990810 </td>
<td> 991014 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
The underlying C ABI defines conventions for calling varargs routines.
Does C++ need, or would it benefit from, any modifications or special cases?
How should we pass references or class objects?
Is any runtime library support required?
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#G5> Resolution</a></b>:
No special cases required -- C++ will follow the C varargs ABI.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr class=small> <a name=G6></a> <td> G-6 </td>
<td> bool parameters </td>
<td> call </td>
<td> closed </td>
<td> all </td>
<td> 991104 </td>
<td> 991202 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
How should we pass bool parameters on IA-64?
Choices are to pass them like ABI ints,
or in predicate registers or register pairs.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#G6> Resolution</a></b>:
No special treatment -- pass bool like char.
</td> </tr>

</table>


<p> <hr> <p>
<h3> Library Interface Issues </h3>

<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=H1></a> <td> H-1 </td>
<td> Runtime library DSO name </td>
<td> tools </td>
<td> closed </td>
<td> SGI </td>
<td> 990616 </td>
<td> 000817 </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Determine the name of the common C++ runtime library DSO,
e.g. <code>libC.so</code>.
If there are to be vendor-specific support libraries which must coexist
in programs from mixed sources, identify naming convention for them.
</td> </tr>
<tr> <td colspan=7>
<b><a href=cxx-closed.html#H1> Resolution</a></b>:
The runtime library will be named <code>libcxa.so</code>.
</td> </tr>

</table>


<p>
<table border=on cellpadding=3>

<tr>
<th> # </th>
<th> Issue </th> <th> Class </th> <th> Status </th>
<th> Source </th> <th> Opened </th> <th> Closed </th>
</tr>

<tr> <a name=H2></a> <td> H-2 </td>
<td> Runtime library API </td>
<td> lif </td>
<td> open </td>
<td> SGI </td>
<td> 990616 </td>
<td> </td>
</tr>
<tr> <td colspan=7>
<b>Summary</b>:
Define the required entrypoints in the common C++ runtime library DSO,
and their prototypes.
</td> </tr>

</table>

<p>
<font color=blue><hr><p>[000413 All]</font>
Because of the extensive use of templates in the standard library,
often with visible helper functions,
it will be very difficult to separate vendor-independent from
vendor-specific runtime support,
and therefore to share a runtime library without at least sharing
the header files.
Committee members will contemplate the possibilities...


<p> <hr> <p>
<h3><a name=ancient> Ancient Revision History </a> </h3>

<p>
<font color=blue>[000830]</font>
Closed <a href=cxx-closed.html#C2>C-2</a>,
<a href=cxx-closed.html#C18>C-18</a>, <a href=cxx-closed.html#F5>F-5</a>,
<a href=cxx-closed.html#G1>G-1</a>, <a href=cxx-closed.html#H1>H-1</a>.
Additions to <a href=#G4>G-4</a>, <a href=#C19>C-19</a>.

<p>
<font color=blue>[000808]</font>
New issues <a href=#C18>C-18</a>, <a href=#C19>C-19</a>.
Closed <a href=cxx-closed.html#C13>C-13</a>.
Tabled <a href=cxx-open.html#F3>F-3</a>, <a href=cxx-open.html#F4>F-4</a>.
Additions to <a href=#C2>C-2</a>, <a href=#G4>G-4</a>.

<p>
<font color=blue>[000728]</font>
Closed <a href=cxx-closed.html#C15>C-15</a>,
<a href=cxx-closed.html#C16>C-16</a>.
Tabled <a href=cxx-open.html#C17>C-17</a>.
Additions to <a href=#C2>C-2</a>.

<p>
<font color=blue>[000706]</font>
Reopened <a href=#G4>G-4</a>.
New issue <a href=#C17>C-17</a>.
Closed <a href=cxx-closed.html#B10>B-10</a>,
<a href=cxx-closed.html#D17>D-17</a>.
Additions to <a href=#C15>C-15</a>, <a href=#C16>C-16</a>.

<p>
<font color=blue>[000628]</font>
New issues <a href=#B10>B-10</a>,
<a href=#C15>C-15</a>, <a href=#C16>C-16</a>,
<a href=#D17>D-17</a>.

<p>
<font color=blue>[000511]</font>
Closed <a href=cxx-closed.html#C14>C-14</a>,
<a href=cxx-closed.html#E1>E-1</a>, <a href=cxx-closed.html#E3>E-3</a>,
<a href=cxx-closed.html#F2>F-2</a>, <a href=cxx-closed.html#G4>G-4</a>.
Additions to <a href=#E2>E-2</a> (tabled).

<p>
<font color=blue>[000504]</font>
Closed <a href=cxx-closed.html#A28>A-28</a>,
<a href=cxx-closed.html#A29>A-29</a>, <a href=cxx-closed.html#C3>C-3</a>,
<a href=cxx-closed.html#C4>C-4</a>, <a href=cxx-closed.html#F6>F-6</a>,
<a href=cxx-closed.html#F7>F-7</a>, <a href=cxx-closed.html#F11>F-11</a>,
<a href=cxx-closed.html#G2>G-2</a>.
Additions to <a href=#C2>C-2</a>,
<a href=cxx-closed.html#F1>F-1</a> (closed),
<a href=#F2>F-2</a>, <a href=#F3>F-3</a>, <a href=#F4>F-4</a>,
<a href=#F10>F-10</a>.

<p>
<font color=blue>[000424]</font>
Additions to <a href=#F3>F-3</a>, <a href=#F6>F-6</a>.

<p>
<font color=blue>[000419]</font>
Additions to
<a href=#A28>A-28</a>, <a href=#A29>A-29</a>,
<a href=#E2>E-2</a>, <a href=#F3>F-3</a>, <a href=#F6>F-6</a>,
<a href=#H2>H-2</a>.
Closed <a href=cxx-closed.html#F8>F-8</a>,
<a href=cxx-closed.html#F9>F-9</a>, <a href=cxx-closed.html#F10>F-10</a>.

<p>
<font color=blue>[000407]</font>
New issue <a href=#A28>A-28</a>, <a href=#A29>A-29</a>.
Additions to <a href=#D12>D-12</a>,
<a href=#F3>F-3</a>, <a href=#F6>F-6</a>,
<a href=#F8>F-8</a>, <a href=#F9>F-9</a>, <a href=#F11>F-11</a>.

<p>
<font color=blue>[000330]</font>
Additions to <a href=#F4>F-4</a>, <a href=#F6>F-6</a>.
Closed <a href=cxx-closed.html#A24>A-24</a>,
<a href=cxx-closed.html#F1>F-1</a>.

<p>
<font color=blue>[000323]</font>
New issues <a href=#F8>F-8</a>, <a href=#F9>F-9</a>.
Additions to <a href=#C4>C-4</a>, <a href=#F1>F-1</a>.

<p>
<font color=blue>[000321]</font>
Additions to <a href=#F1>F-1</a>, <a href=#F6>F-6</a>.

<p>
<font color=blue>[000313]</font>
New issues <a href=#C13>C-13</a>, <a href=#C14>C-14</a>.
Closed <a href=#C11>C-11</a>, <a href=#C12>C-12</a>.
Additions to <a href=#A24>A-24</a>, <a href=#C4>C-4</a>, <a href=#F1>F-1</a>.

<p>
<font color=blue>[000308]</font>
Closed <a href=#A26>A-26</a>, <a href=#A27>A-27</a>,
<a href=#B9>B-9</a>.
Add Limits section to ABI layout document.

<p>
<font color=blue>[000302]</font>
Additions to closed <a href=cxx-closed.html#A20>A-20</a>,
<a href=cxx-closed.html#A21>A-21</a>.
Additions to <a href=#C11>C-11</a>,

<p>
<font color=blue>[000228]</font>
New issues <a href=#A26>A-26</a>, <a href=#A27>A-27</a>,
<a href=#F7>F-7</a>.

<p>
<font color=blue>[000214]</font>
Closed <a href=#A21>A-21</a>, <a href=#A25>A-25</a>.
Additions to <a href=#A23>A-23</a>, <a href=#C4>C-4</a>,
<a href=#F1>F-1</a>, <a href=#F5>F-5</a>.
New issue <a href=#B9>B-9</a>.

<p>
<font color=blue>[000214]</font>
Additions to <a href=#A21>A-21</a>, <a href=#A23>A-23</a>,
<a href=#A24>A-24</a>, <a href=#F1>F-1</a>.
New issue <a href=#F5>F-5</a>.

<p>
<font color=blue>[000204]</font>
Closed <a href=#A22>A-22</a>, <a href=#D11>D-11</a>.
Additions to <a href=#A23>A-23</a>, <a href=#A24>A-24</a>,
<a href=#D12>D-12</a>.
New issue <a href=#A25>A-25</a>.

<p>
<font color=blue>[000131]</font>
Additions to <a href=#A20>A-20</a>, <a href=#A21>A-21</a>,
<a href=#D11>D-11</a>, <a href=#F1>F-1</a>.
New issues <a href=#A22>A-22</a>, <a href=#A23>A-23</a>,
<a href=#A24>A-24</a>, <a href=#C11>C-11</a>, <a href=#C12>C-12</a>.

<p>
<font color=blue>[000121]</font>
Fix links.
Closed <a href=#A19>A-19</a>, <a href=#A20>A-20</a>,
<a href=#D10>D-10</a>, <a href=#D13>D-13</a>.
Additions to <a href=#A21>A-21</a>,
<a href=#D1>D-1</a>, <a href=#D11>D-11</a>,
<a href=#D12>D-12</a>, <a href=#D14>D-14</a>.

<p>
<font color=blue>[000120]</font>
Closed <a href=#A17>A-17</a>, <a href=#A18>A-18</a>,
<a href=#D9>D-9</a>, <a href=#D16>D-16</a>.
Additions to <a href=#A19>A-19</a>.
New issues <a href=#A20>A-20</a>, <a href=#A21>A-21</a>.

<p>
<font color=blue>[000112]</font>
Closed <a href=#A15>A-15</a>, <a href=#A16>A-16</a>,
<a href=#D2>D-2</a>, <a href=#D3>D-3</a>,
<a href=#D8>D-8</a>, <a href=#D15>D-15</a>.
Additions to <a href=#A17>A-17</a>, <a href=#A18>A-18</a>,
<a href=#D9>D-9</a>, <a href=#D11>D-11</a>,
<a href=#D13>D-13</a>, <a href=#D14>D-14</a>, <a href=#D16>D-16</a>.
New issue <a href=#A19>A-19</a> (split from A-17).

<p>
<font color=blue>[000105]</font>
Closed <a href=#D0>D-0</a>.
Additions to <a href=#D1>D-1</a>, <a href=#D9>D-9</a>.
New issues <a href=#D10>D-10</a> to <a href=#D16>D-16</a>.

<p>
<font color=blue>[000103]</font>
Additions to <a href=#A17>A-17</a>.

<p>
<font color=blue>[991230]</font>
Clarify definition of nearly empty class.

<p>
<font color=blue>[991221]</font>
New issues <a href=#A15>A-15</a>, <a href=#A16>A-16</a>,
<a href=#A17>A-17</a>, <a href=#A18>A-18</a>.
Reopened <a href=#C3>C-3</a>.
Additions to <a href=cxx-closed.html#C3>C-3</a> (closed).

<p>
<font color=blue>[991209]</font>
Additions to <a href=#D1>D-1</a>,
<a href=#D2>D-2</a>, <a href=#D3>D-3</a>.
Closed <a href=cxx-closed.html#D4>D-4</a>,
<a href=cxx-closed.html#D7>D-7</a>.

<p>
<font color=blue>[991202]</font>
Additions to <a href=#B4>B-4</a>
(<a href=cxx-closed.html#B4>closed</a>),
<a href=#C2>C-2</a>, <a href=#D0>D-*</a>.
Closed <a href=cxx-closed.html#B1>B-1</a>,
<a href=cxx-closed.html#C1>C-1</a>,
<a href=cxx-closed.html#C3>C-3</a>,
<a href=cxx-closed.html#G3>G-3</a>,
<a href=cxx-closed.html#G6>G-6</a>.

<p>
<font color=blue>[991129]</font>
Additions to <a href=#B1>B-1</a>, <a href=#F2>F-2</a>, <a href=#G3>G-3</a>.
Closed <a href=cxx-closed.html#B5>B-5</a>.

<p>
<font color=blue>[991104]</font>
New issue <a href=#G6>G-6</a>.
Additions to <a href=#C4>C-4</a>.
Closed <a href=cxx-closed.html#C5>C-5</a>,
<a href=cxx-closed.html#C6>C-6</a>,
<a href=cxx-closed.html#C9>C-9</a>.

<p>
<font color=blue>[991028]</font>
Opened <a href=#C9>C-9</a>, <a href=#C10>C-10</a>.
Closed <a href=cxx-closed.html#A6>A-6</a>,
<a href=cxx-closed.html#B6>B-6</a>,
<a href=cxx-closed.html#C10>C-10</a>.
Additions to <a href=#C5>C-5</a>, <a href=#C6>C-6</a>,
<a href=#F1>F-1</a>, <a href=#F2>F-2</a>, <a href=#F3>F-3</a>.

<p>
<font color=blue>[991026]</font>
Additions to <a href=#F1>F-1</a>.

<p>
<font color=blue>[991012]</font>
Closed <a href=cxx-closed.html#B8>B-8</a>,
<a href=cxx-closed.html#G5>G-5</a>.
Additions to <a href=#A6>A-6</a>, <a href=#B5>B-5</a>,
<a href=#C5>C-5</a>.

<p>
<font color=blue>[991012]</font>
Closed <a href=cxx-closed.html#D5>D-5</a>,
<a href=cxx-closed.html#D6>D-6</a>.
Additions to <a href=#B4>B-4</a>, <a href=#B5>B-5</a>,
<a href=#D7>D-7</a>.

<p>
<font color=blue>[991005]</font>
New issue <a href=#F4>F-4</a>.
Additions to <a href=#A6>A-6</a>, <a href=#B5>B-5</a>, <a href=#B6>B-6</a>,
<a href=#C4>C-4</a>, <a href=#D5>D-5</a>, <a href=#D7>D-7</a>.

<p>
<font color=blue>[990929]</font>
Additions to <a href=#D0>D-*</a>, <a href=#D9>D-9</a>.

<p>
<font color=blue>[990914]</font>
Additions to <a href=#B1>B-1</a>, <a href=#D0>D-*</a>, <a href=#D9>D-9</a>.

<p>
<font color=blue>[990908]</font>
New issue <a href=#D9>D-9</a>.
Additions to <a href=#B1>B-1</a>, <a href=#D0>D-*</a>,
<a href=#D2>D-2</a>, <a href=#D4>D-4</a>,
<a href=#D5>D-5</a>, <a href=#D6>D-6</a>.

<p>
<font color=blue>[990901]</font>
Additions to <a href=#A6>A-6</a>, <a href=#B6>B-6</a>.

<p>
<font color=blue>[990825]</font>
Additions to <a href=#A6>A-6</a>, <a href=#B6>B-6</a>,
<a href=#C5>C-5</a>, <a href=#D0>D-*</a>.

<p>
<font color=blue>[990813]</font>
Closed <a href=cxx-closed.html#A11>A-11</a>.
Additions to <a href=#A6>A-6</a>,
<a href=#B1>B-1</a>, <a href=#B6>B-6</a>, <a href=#B8>B-8</a>,
<a href=#C2>C-2</a>,
<a href=#G5>G-5</a>.

<p>
<font color=blue>[990810]</font>
New issue <a href=#G5>G-5</a>.
Additions to <a href=#B6>B-6</a>, <a href=#C2>C-2</a>, <a href=#C3>C-3</a>.

<p>
<font color=blue>[990805]</font>
Closed A-12, A-14, B-3, B-4, B-7, C-7.
Additions to <a href=#A6>A-6</a>, <a href=#A11>A-11</a>,
<a href=#B1>B-1</a>, <a href=#B6>B-6</a>, <a href=#F1>F-1</a>.

<p>
<font color=blue>[990729]</font>
Closed A-7.
Additions to A-11, A-12, C-2.
Summary added for A-12.
New issue A-14.

<p>
<font color=blue>[990727]</font>
Closed B-2, C-8.
Additions to A-9 (closed), C-2.
Summaries added for C-4, C-6, D-1 to D-4.

<p>
<font color=blue>[990720]</font>
Additions to B-2, B-5, C-2, D-1.

<p>
<font color=blue>[990701]</font>
Closed A-3, A-5, A-10, A-13.
Additions to A-6, B-6, B-7, B-8, C-2, C-7.

<p>
<font color=blue>[990625]</font>
Closed A-1, A-2, A-4, A-8, A-9.
Additions to A-3, A-5, A-7, B-4, B-5, B-7, G-3, G-4.
New issues B-6, B-7, B-8, C-7, C-8.

<p>
<font color=blue>[990616]</font>
Added HP summaries.
Added sketchy notes from 990610 discussions (A and B issues).
A-10 was intended by HP as something different than I described,
so it was renamed, and a new issue A-13 opened as an SGI issue.
HP did not submit A-12, so relabeled as Sun's (is that right?).
Added library interface issues, H-1 and H-2.


<p>
<hr>

</BODY>
</HTML>