Revisions

[001110] Reopened and reclosed A-5. Closed A-30, A-31, D-14, D-18, G-4.

[001107] New issues A-30, A-31. D-18.

[000901] Closed C-19.

Ancient revision history.

Definitions

The issues below make use of the following definitions:

dynamic class

A class that requires a virtual pointer, due to either virtual functions or virtual bases.

empty class

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.

nearly empty class

A class that:

• has no non-static data members other than zero-width bitfields,
• has no base classes that are not either empty or nearly empty,
• has at most one nearly empty base class, and
• has at least one virtual function, possibly inherited from a base class.

Such a class contains only a Vptr.

vague linkage

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.

Issue Status

Object Layout Issues

#	Issue	Class	Status	Source	Opened	Closed
A-1	Vptr location	data	closed	SGI	990520	990624
Summary: Where is the Vptr stored in an object (first or last are the usual answers).
Resolution : First.

#	Issue	Class	Status	Source	Opened	Closed
A-2	Virtual base classes	data	closed	SGI	990520	990624
Summary: Where are the virtual base subobjects placed in the class layout? How are data member accesses to them handled?
Resolution : 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).

#	Issue	Class	Status	Source	Opened	Closed
A-3	Multiple inheritance	data	closed	SGI	990520	990701
Summary: Define the class layout in the presence of multiple base classes.
Resolution : 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.

#	Issue	Class	Status	Source	Opened	Closed
A-4	Empty base classes	data	closed	SGI	990520	990624
Summary: Where are empty base classes allocated?
Resolution : At offset zero if possible. See A-9.

#	Issue	Class	Status	Source	Opened	Closed
A-5	Empty parameters	data	closed	SGI	990520	001117
Summary: When passing a parameter with an empty class type by value, what is the convention?
Resolution : 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.

#	Issue	Class	Status	Source	Opened	Closed
A-6	RTTI .o representation	data call ps	closed	SGI	990520	991028
Summary: Define the data structure to be used for RTTI, that is: for user type_info calls; for dynamic_cast implementation; and for exception-handling.
Resolution : Defined in the Draft C++ ABI for IA-64 document.

#	Issue	Class	Status	Source	Opened	Closed
A-7	Vptr sharing with primary base class	data	closed	HP	990603	990729
Summary: It is in general possible to share the virtual pointer with a dynamic base class (the primary base class). Which base class do we use for this?
Resolution : Share with the first non-virtual dynamic base class, or if none with the first nearly empty virtual base class.

#	Issue	Class	Status	Source	Opened	Closed
A-8	(Virtual) base class alignment	data	closed	HP	990603	990624
Summary: 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?
Resolution : The derived class will have at least the alignment of any base class.

#	Issue	Class	Status	Source	Opened	Closed
A-9	Sorting fields as allowed by [class.mem]/12	data	closed	HP	990603	990624
Summary: 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?
Resolution : See the Draft C++ ABI for IA-64 .

#	Issue	Class	Status	Source	Opened	Closed
A-10	Class parameters in registers	call	closed	HP	990603	990701
Summary: 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 this pointer in that case?
Resolution : Non-POD C++ objects are passed like C structs, except for cases with non-trivial copy constructors identified in C-7.

#	Issue	Class	Status	Source	Opened	Closed
A-11	Pointers to member functions	data	closed	Cygnus	990603	990812
Summary: How should pointers to member functions be represented?
Resolution: As a pair of values, a "pointer" and a this adjustment. See the closed list for a more detailed description.

#	Issue	Class	Status	Source	Opened	Closed
A-12	Merging secondary vtables	data	closed	Sun	990610	990805
Summary: 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.
Resolution: Concatenate the Vtables associated with a class in the same order that the corresponding base subobjects are allocated in the object.

#	Issue	Class	Status	Source	Opened	Closed
A-13	Parameter struct field promotion	call	closed	SGI	990603	990701
Summary: 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?
Resolution: No special treatment will be specified by the ABI.

#	Issue	Class	Status	Source	Opened	Closed
A-14	Pointers to data members	data	closed	SGI	990729	990805
Summary: How should pointers to data members be represented?
Resolution: Represented as one plus the offset from the base address.

#	Issue	Class	Status	Source	Opened	Closed
A-15	Empty bit-fields	data	closed	CodeSourcery	991214	000106
Summary: How are zero-length bit-fields handled?
Resolution: Zero-length bit-fields do not prevent a class from being considered empty or nearly empty.

#	Issue	Class	Status	Source	Opened	Closed
A-16	Nearly empty virtual bases	data	closed	SGI	991228	000106
Summary: 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?
Resolution: Virtual base classes do not prevent a class from being considered nearly empty.

#	Issue	Class	Status	Source	Opened	Closed
A-17	Primary indirect virtual base allocation	data	closed	SGI	991228	000113
Summary: 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?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
A-18	Virtual base alignment	data	closed	SGI	991228	000113
Summary: Should virtual bases have a different effect on class alignment than other components?
Resolution: Yes. When allocating the non-virtual part of a base class, use its non-virtual allignment, i.e. ignoring its virtual bases' contributions.

#	Issue	Class	Status	Source	Opened	Closed
A-19	Primary indirect virtual base choice	data	closed	All	000106	000120
Summary: 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?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
A-20	Operator new array cookies	data	closed	All	000113	000120
Summary: 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.
Resolution: In principle, place cookie immediately before array, aligned naturally. Use no cookie for element types with no destructors. See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
A-21	Placement new array cookies	data	closed	All	000113	000217
Summary: 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?
Resolution: Use no cookie for element types with no destructors, nor for ::operator new(size_t, void*). Otherwise, use a cookie as in issue A-20. See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
A-22	RTTI for reference types	data	closed	CodeSourcery	000119	000203
Summary: __reference_type_info does not appear to be necessary.
Resolution: Remove it.

#	Issue	Class	Status	Source	Opened	Closed
A-23	RTTI class descriptors	data	closed	CodeSourcery	000124	000302
Summary: Resolve several questions about the RTTI representation of class types.
Resolution: See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
A-24	RTTI for incomplete types	data	closed	CodeSourcery	000126	000330
Summary: How does RTTI represent incomplete types?
Resolution: 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 Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
A-25	Excess-width bitfields	data	closed	IBM	000204	000217
Summary: C++ allows bitfields with a larger size specified than that required by the declared type, e.g. int f: 64. How should they be allocated?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
A-26	NULL pointers to member functions	data	closed	CodeSourcery	000221	000302
Summary: How are NULL pointers to member functions represented?
Resolution: A NULL pointer is represented by a 0 value of ptr, and the value of adj is irrelevant.

#	Issue	Class	Status	Source	Opened	Closed
A-27	NULL pointers to data members	data	closed	CodeSourcery	000222	000302
Summary: How are NULL pointers to member data represented?
Resolution: A NULL pointer is represented by the value -1.

#	Issue	Class	Status	Source	Opened	Closed
A-28	RTTI equality testing	data	closed	CodeSourcery	000406	000504
Summary: Can we get back the ability to do a simple test for RTTI equality?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
A-29	RTTI pointer-to-member	data	closed	CodeSourcery	000407	000504
Summary: Derive __pointer_to_member_type_info from __pointer_type_info.
Resolution: 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).

#	Issue	Class	Status	Source	Opened	Closed
A-30	RTTI portability	data	closed	HUB	001012	001109
Summary: What must be specified to produce RTTI portability? Are member layouts specified? Names? Virtual functions?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
A-31	Overlaying tail padding	data	closed	CodeSourcery	001019	001109
Summary: Should we change the decision to overlay tail padding in class layout? For volatile members? In general?
Resolution: The overlaying of tail padding is eliminated, but we will retain the treatment of empty bases.

Virtual Function Handling Issues

#	Issue	Class	Status	Source	Opened	Closed
B-1	Adjustment of "this" pointer (e.g. thunks)	data call	closed	SGI	990520	991202
Summary: There are several methods for adjusting the this 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.
Resolution: See the writeup in the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
B-2	Covariant return types	call	closed	SGI	990520	990722
Summary: 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.
Resolution: Provide a separate Vtable entry for each return type.

#	Issue	Class	Status	Source	Opened	Closed
B-3	Allowed caching of vtable contents	call	closed	HP	990603	990805
Summary: 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?
Resolution: Caching is allowed within a member function.

#	Issue	Class	Status	Source	Opened	Closed
B-4	Function descriptors in vtable	data	closed	HP	990603	990805
Summary: 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.
Resolution: The Vtable will contain a function address/GP pair.

[991007 All] Note that, though this issue was closed, it may prove necessary to reopen it if the underlying C ABI treatment of function pointers changes.

#	Issue	Class	Status	Source	Opened	Closed
B-5	Where are vtables emitted?	data	closed	HP	990603	991118
Summary: 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 vague linkage.)
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
B-6	Virtual function table layout	data	closed	SGI	990520	991028
Summary: What is the layout of the Vtable?
Resolution: See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
B-7	Objects and Vtables in shared memory	data	closed	HP	990624	990805
Summary: Is it possible to allocate objects in shared memory? For dynamic objects, this implies that the Vtable must also be in shared memory.
Resolution: No special representation is useful in support of shared memory.

#	Issue	Class	Status	Source	Opened	Closed
B-8	dynamic_cast	data	closed	SGI	990628	991014
Summary: 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*?
Resolution: The vtable will contain an offset to the beginning of the complete object, and a pointer to the typeinfo object.

#	Issue	Class	Status	Source	Opened	Closed
B-9	Primary base vtable embedding	data	closed	Cygnus	000217	000302
Summary: Resolve the embedding of the vtable for the primary base class in the derived class vtable.
Resolution: Any class with virtual bases shall contain vbase pointers for all of its virtual bases.

#	Issue	Class	Status	Source	Opened	Closed
B-10	Pure virtual runtime	call	closed	CodeSourcery	000629	000706
Summary: Define a runtime proxy routine for pure virtual functions.
Resolution: Define such a runtime routine, with implementation-defined behavior.

Object Construction/Destruction Issues

#	Issue	Class	Status	Source	Opened	Closed
C-1	Interaction with .init/.fini	lif ps	closed	SGI	990520	991202
Summary: 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. 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. 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.
Resolution: Use .init_array and .fini_array sections.

#	Issue	Class	Status	Source	Opened	Closed
C-2	Order of ctors/dtors w.r.t. link	lif ps	closed	HP	990603	000817
Summary: 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.)
Resolution: Accepted method based on IBM's specification. See Draft C++ ABI for IA-64, Section 3.3.4.

#	Issue	Class	Status	Source	Opened	Closed
C-3	Order of ctors/dtors w.r.t. DSOs	ps	closed	HP	990603	000504
Summary: 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. 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.
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
C-4	Construction vtables	call	closed	Cygnus	990603	000504
Summary: 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.
Resolution: Accept Compaq proposal as currently documented in the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
C-5	Calling destructors	call	closed	Sun	990603	991104
Summary: 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?
Resolution: Destructors are called with a reference to this. 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.

#	Issue	Class	Status	Source	Opened	Closed
C-6	Extra parameters to constructors	call	closed	Cygnus	990603	991104
Summary: 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?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
C-7	Passing value parameters by reference	call	closed	All	990624	990805
Summary: 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.
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
C-8	Returning classes with non-trival copy constructors	call	closed	All	990625	990722
Summary: How do we return classes with non-trivial copy constructors?
Resolution: The caller allocates space, and passes a pointer as an implicit first parameter (prior to the implicit this parameter).

#	Issue	Class	Status	Source	Opened	Closed
C-9	Passing parameters with ctors/dtors	call	closed	All	991028	991104
Summary: Where do allocation, construction, destruction, and deallocation occur for value parameters?
Resolution: closed issues list.

#	Issue	Class	Status	Source	Opened	Closed
C-10	Synthesized copy assignments	call	closed	All	991028	991028
Summary: Should we specify special treatment for synthesized copy assignments, to avoid multiple copies of virtual bases?
Resolution: No.

#	Issue	Class	Status	Source	Opened	Closed
C-11	Array constructors/destructors	call	closed	Cygnus	000130	000309
Summary: How are constructors/destructors run for arrays? Many compilers use a __vec_new function; g++ doesn't, to allow for inlining of constructors.
Resolution: Define standard library entries for array construction/destruction. See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
C-12	Constructor return values	call	closed	Cygnus	000130	000309
Summary: What is the return value of a constructor? Void, this, ...?
Resolution: Void.

#	Issue	Class	Status	Source	Opened	Closed
C-13	Allocating constructors	call	closed	HP	000309	000803
Summary: Should we define allocating constructors?
Resolution: 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).

#	Issue	Class	Status	Source	Opened	Closed
C-14	Local-scope dynamic constructors	data	closed	all	000309	000511
Summary: 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.
Resolution: The size of the guard variable is 64 bits. The low-order byte shall contains a boolean initialization flag.

#	Issue	Class	Status	Source	Opened	Closed
C-15	Alternate array allocators	call	closed	CodeSourcery	000628	000720
Summary: Allow alternate allocators/deallocators to __cxa_vec_new and __cxa_vec_delete.
Resolution: 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 Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
C-16	Copy constructor runtime	call	closed	CodeSourcery	000628	000720
Summary: Define a runtime support routine for copy constructors.
Resolution: Add a new runtime for vector copy construction. See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
C-17	Uncatch exception runtime	call	tabled	all	000706	000720
Summary: Define a runtime support routine to uncatch the current exception.

[000706 All] 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.

[000720 All] 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.

#	Issue	Class	Status	Source	Opened	Closed
C-18	Result buffers	call	closed	SGI	000724	000817
Summary: 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?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
C-19	NULL ctor/dtor API parameters	call	closed	CodeSourcery	000806	000831
Summary: Allow NULL constructor/destructor parameters whereever it makes sense in the Section 3.3 APIs.
Resolution: Accepted as proposed.

Exception Handling Issues

#	Issue	Class	Status	Source	Opened	Closed
D-0	Exception handling framework	lib ps	closed	SGI	990520	991216
Summary: Define the general framework for exception handling, including Level I (psABI unwinding API) and Level II (C++ ABI exception handling API).
Resolution: See the HP proposal, accepted as a working paper, and discussions in the closed issues page.

#	Issue	Class	Status	Source	Opened	Closed
D-1	Language-specific data area format	lib ps	open	SGI	990520
Summary: 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.

[990715 Cygnus -- Jason] The languge-specific part of the EH stack in g++ contains these elements:

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

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

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.

[991209 all] Observe that this issue is part of a level 3 specification, i.e. part of a common runtime specification, but not strictly part of the ABI. It is described as part of the EH working paper from HP.

[991216 all] The __typeinfo type defined in 7.6 of the working paper should be replaced by the ABI standard type_info. The treatment of predefined types must be specified.

[000126 editor] This issue is effectively closed by virtue of accepting the working paper (D-0), but I will not close it officially until the working paper reflects the __typeinfo change.

#	Issue	Class	Status	Source	Opened	Closed
D-2	Unwind personality routines	lib ps	closed	SGI	990520	000106
Summary: 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).
Resolution: See the exception handling specification, level 1, and the working paper.

#	Issue	Class	Status	Source	Opened	Closed
D-3	Unwind process clarification	lib ps	closed	SGI	990520	000106
Summary: 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).
Resolution: See the exception handling specification.

#	Issue	Class	Status	Source	Opened	Closed
D-4	Unwind routines nested?	lib ps	closed	SGI	990520	991209
Summary: 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?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
D-5	Interaction with other languages (e.g. Java)	lib ps	closed	HP	990603	991007
Summary: 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?
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
D-6	Allow resumption in other languages?	lib ps	closed	HP	990603	991007
Summary: 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?
Resolution: 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.

[990908 SGI -- Jim] 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.

#	Issue	Class	Status	Source	Opened	Closed
D-7	Interaction with signals or asynch events	lib ps	closed	HP	990603	991209
Summary: 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, uncaught_exception()). Or we could allow even an exception to be thrown, if it does not exit the handler.
Resolution: This ABI requires no support beyond the Standard requirements.

#	Issue	Class	Status	Source	Opened	Closed
D-8	Interaction with threads packages	lib ps	closed	SGI	990603	000106
Summary: What happens when an exception is not caught in the thread where raised? What does uncaught_exception() return if another thread is currently processing an exception?
Resolution: With one exception, exception handling is entirely per-thread -- exceptions must be caught in the thread where raised, and queries about them (e.g. uncaught_exception()) are answered only with respect to the thread doing the query. The only global exception behavior is handler registration -- see issue D-15.

#	Issue	Class	Status	Source	Opened	Closed
D-9	longjmp interaction	lib ps	closed	IBM	990908	000113
Summary: Does longjmp run destructors?
Resolution: Define an alternate routine, longjmp_unwind in namespace abi, defined in new header cxxabi.h, which always does full cleanup during unwinding.

#	Issue	Class	Status	Source	Opened	Closed
D-10	psABI proposal	lib ps	closed	all	991216	000120
Summary: Solidify the Level I (psABI) specification and submit it to the base ABI group.
Resolution: See the exception handling specification.

#	Issue	Class	Status	Source	Opened	Closed
D-11	pthreads interface	lib ps	closed	all	991216	000203
Summary: 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.
Resolution: No specification necessary. This is Level 3 material.

#	Issue	Class	Status	Source	Opened	Closed
D-12	Table location	lib ps	closed	all	991216	000504
Summary: Determine constraints on the location of the unwind table and the unwind information table.
Resolution: The unwind tables must reside in the text segment they describe.

#	Issue	Class	Status	Source	Opened	Closed
D-13	_Unwind_ForcedUnwind	lib ps	closed	all	991216	000120
Summary: Define the interface of _Unwind_ForcedUnwind.
Resolution: See the exception handling specification.

#	Issue	Class	Status	Source	Opened	Closed
D-14	__cxa_begin/end_catch	lib	closed	all	991216	001109
Summary: Define the interfaces of __cxa_begin_catch and __cxa_end_catch.
Resolution: See the exception handling specification.

#	Issue	Class	Status	Source	Opened	Closed
D-15	Terminate handler and threads	lib	closed	all	991216	000106
Summary: Define how the terminate and unexpected handler registration interacts with threads.
Resolution: Handler registration applies to all threads.

#	Issue	Class	Status	Source	Opened	Closed
D-16	Exception specifications	lib	closed	all	991216	000113
Summary: How is the type list for an exception specification represented in the action records?
Resolution: As specified in the HP document

#	Issue	Class	Status	Source	Opened	Closed
D-17	bad_cast, bad_typeid runtime	call	closed	CodeSourcery	000629	000706
Summary: Define runtime support routines for throwing bad_cast and bad_typeid exceptions.
Resolution: Accepted as proposed originally. See draft EH Specification.

#	Issue	Class	Status	Source	Opened	Closed
D-18	__cxa_throw_type_info	lib	closed	all	001012	001109
Summary: Should we replace the __cxa_throw_type_info pointer in the exception object by a pair of pointers to a std::type_info and a destructor?
Resolution: Make the replacement. See Sections 2.2.1 and 2.4.3 of the See draft EH Specification.

Template Instantiation Model Issues

#	Issue	Class	Status	Source	Opened	Closed
E	Template Instantiation Model
E-1	When does instantiation occur?	tools	closed	SGI	990520	000511
Summary: There are two principal models for instantiation. The early instantiation (or Borland) model performs all instantiation at compile time, potentially resulting in extra copies which are removed at link time. The pre-link instantiation model identifies the required instantiations prior to linking and instantiates them via a special compile step.
Resolution: Non-export templates are instantiated where referenced in COMDAT groups. See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
E-2	Export template model	tools	tabled	SGI	990520
Summary: 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?

[000413 All] 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.

[000423 EDG -- Daveed] 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.

[000511 All] We will not deal with export templates at this time, given no existing implementations to serve as models.

#	Issue	Class	Status	Source	Opened	Closed
E-3	Template repository	tools	closed	HP	990603	000511
Summary: 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.
Resolution: COMDAT emission and naming for non-export templates is specified in the Draft C++ ABI for IA-64.

Name Mangling Issues

#	Issue	Class	Status	Source	Opened	Closed
F-1	Mangling convention	call	closed	SGI	990520	000330
Summary: 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?
Resolution: See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
F-2	Mangled name size	call g	closed	SGI	990520	000511
Summary: 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. 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.
Resolution: The current mangling solution is considered an adequate solution to this problem.

#	Issue	Class	Status	Source	Opened	Closed
F-3	Consistency checks	call g	tabled	SGI	990520
Summary: Define a mechanism to support consistency checks, e.g. in the linker, in cases where the Standard forbids inconsistency but does not require detection.

[991028 all] 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.

Several examples are:

1. A template instantiation may conflict with a full specialization (in different translation units).

2. Functions may be declared with different throw specifications.

3. Functions may be declared with different return types.

4. Template formal parameter names would help improve instantiation error messages.

[000406 all]

1. Instantiation vs. specialization is tabled pending a specific proposal.
2. Function throw specifications are issue F-4.
3. Function return types are issue F-10.
4. There is resistance to doing something with formal parameter names. Someone will hunt up John Spicer's commentary on the idea.

[000417 Compaq -- Coleen] I propose that partial specializations should be mangled differently than template instantiations. The reasons:

1. It's the standard. 14.5.4 pp 3:

   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).

   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?

2. 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.

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:

1. 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?

2. 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.)

    <template-args> ::= I <template-arg>+ E
    <template-arg> ::= <type>                     # type
    <template-arg> ::= D <type> E                 # partially specialize'D'
    <template-arg> ::= L <type> <value number> E  # literal
    <template-arg> ::= LZ <encoding> E            # external name
    <template-arg> ::= X <expression> E           # expression

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

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

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

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

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

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

[000417 CodeSourcery -- Mark] I'm not persuaded that we should mangle specializations and instantiations differently. If I understand Colleen's proposal, these two functions:

  template <class T> void f(T);
  template <> void f<int>(int) { }

  template <class T> void f(T) { }
  template void f<int>(int);

Here are my objections:

• 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.

• I don't think the standard doesn't require a diagnostic.

• 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.)

• 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.

[000418 SGI -- John] 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).

1. 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.

2. 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

3. 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.

4. The specific mangling scheme that Colleen proposes does not distinguish all the necessary variants. Consider the declarations

      template <class T> struct X     { void foo();};
      template <class T> struct X<T*> { void foo();};
      template <> struct X<int*>      { void foo();};
   
   

   A program that declares

     X<int*> x;
   
   

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

     void X<int*>::foo(void).
   
   

   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.

[000504 All] The SGI Interface ELF section specification 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.

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.

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.

[000803 all] There is no current interest in tackling this. Table the issue.

#	Issue	Class	Status	Source	Opened	Closed
F-4	Empty throw specs	call g	tabled	HP	990930
Summary: 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?

[000330 all] 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.

[000504 All] See the comment for issue F-3 above.

[000803 all] There is no current interest in tackling this. Table the issue.

#	Issue	Class	Status	Source	Opened	Closed
F-5	ILP32 vs. LP64	call	closed	HP	000210	000824
Summary: 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?
Resolution: Withdrawn -- no action.

#	Issue	Class	Status	Source	Opened	Closed
F-6	Demangling	lib	closed	Cygnus	000210	000504
Summary: Users may sometimes want to get demangled names. Should we provide an entry point for calling a demangler?
Resolution: Provide a simple demangler interface callable from C. See the Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
F-7	Mangling statics	call	closed	HP	000223	000504
Summary: What, if anything, should we do about mangling the names of objects in static functions in case a compiler chooses to inline them?
Resolution: 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 Draft C++ ABI for IA-64.

#	Issue	Class	Status	Source	Opened	Closed
F-8	Identifiers with unicode letters	call	closed	HU-Berlin	000323	000413
Summary: How should we mangle names containing unicode letters?
Resolution: Follow the underlying C ABI.

#	Issue	Class	Status	Source	Opened	Closed
F-9	Strings with unicode letters	call	closed	HU-Berlin	000323	000413
Summary: How should we handle the object file representation of narrow and wide string literals containing unicode letters?
Resolution: Follow the underlying C ABI.

#	Issue	Class	Status	Source	Opened	Closed
F-10	Mangling function return types	call	closed	all	000330	000413
Summary: Should we always mangle the return type of a function?
Resolution: No. It is mangled only for template instantiations/specializations.

#	Issue	Class	Status	Source	Opened	Closed
F-11	Hash for local strings	call	closed	all	000330	000504
Summary: How should we hash strings for local name mangling?
Resolution: Strings are mangled with a discriminator consisting of "s" followed by a sequence ID. See the Draft C++ ABI for IA-64.

Miscellaneous Issues

#	Issue	Class	Status	Source	Opened	Closed
G-1	Basic command line options	tools	closed	HP	990603	000824
Summary: Can we agree on basic command line options (compiler and linker) for fundamental functionality, possibly allowing portable makefiles?
Resolution: Withdrawn -- no action.

#	Issue	Class	Status	Source	Opened	Closed
G-2	Detection of ODR violations	call	closed	Sun	990603	000504
Summary: [Sun] (See also F-3.)
Resolution: This is a duplicate. See F-3, F-4, F-10.

#	Issue	Class	Status	Source	Opened	Closed
G-3	Inlined routine linkage	call	closed	Sun	990603	991202
Summary: 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.
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
G-4	Dynamic init of local static objects and multithreading	call	closed	SCO	990607	001109
Summary: 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.
Resolution: 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.

#	Issue	Class	Status	Source	Opened	Closed
G-5	Varargs routine interface	call	closed	HU-B	990810	991014
Summary: 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?
Resolution: No special cases required -- C++ will follow the C varargs ABI.

#	Issue	Class	Status	Source	Opened	Closed
G-6	bool parameters	call	closed	all	991104	991202
Summary: How should we pass bool parameters on IA-64? Choices are to pass them like ABI ints, or in predicate registers or register pairs.
Resolution: No special treatment -- pass bool like char.

Library Interface Issues

#	Issue	Class	Status	Source	Opened	Closed
H-1	Runtime library DSO name	tools	closed	SGI	990616	000817
Summary: Determine the name of the common C++ runtime library DSO, e.g. libC.so. If there are to be vendor-specific support libraries which must coexist in programs from mixed sources, identify naming convention for them.
Resolution: The runtime library will be named libcxa.so.

#	Issue	Class	Status	Source	Opened	Closed
H-2	Runtime library API	lif	open	SGI	990616
Summary: Define the required entrypoints in the common C++ runtime library DSO, and their prototypes.

[000413 All] 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...

Ancient Revision History

[000830] Closed C-2, C-18, F-5, G-1, H-1. Additions to G-4, C-19.

[000808] New issues C-18, C-19. Closed C-13. Tabled F-3, F-4. Additions to C-2, G-4.

[000728] Closed C-15, C-16. Tabled C-17. Additions to C-2.

[000706] Reopened G-4. New issue C-17. Closed B-10, D-17. Additions to C-15, C-16.

[000628] New issues B-10, C-15, C-16, D-17.

[000511] Closed C-14, E-1, E-3, F-2, G-4. Additions to E-2 (tabled).

[000504] Closed A-28, A-29, C-3, C-4, F-6, F-7, F-11, G-2. Additions to C-2, F-1 (closed), F-2, F-3, F-4, F-10.

[000424] Additions to F-3, F-6.

[000419] Additions to A-28, A-29, E-2, F-3, F-6, H-2. Closed F-8, F-9, F-10.

[000407] New issue A-28, A-29. Additions to D-12, F-3, F-6, F-8, F-9, F-11.

[000330] Additions to F-4, F-6. Closed A-24, F-1.

[000323] New issues F-8, F-9. Additions to C-4, F-1.

[000321] Additions to F-1, F-6.

[000313] New issues C-13, C-14. Closed C-11, C-12. Additions to A-24, C-4, F-1.

[000308] Closed A-26, A-27, B-9. Add Limits section to ABI layout document.

[000302] Additions to closed A-20, A-21. Additions to C-11,

[000228] New issues A-26, A-27, F-7.

[000214] Closed A-21, A-25. Additions to A-23, C-4, F-1, F-5. New issue B-9.

[000214] Additions to A-21, A-23, A-24, F-1. New issue F-5.

[000204] Closed A-22, D-11. Additions to A-23, A-24, D-12. New issue A-25.

[000131] Additions to A-20, A-21, D-11, F-1. New issues A-22, A-23, A-24, C-11, C-12.

[000121] Fix links. Closed A-19, A-20, D-10, D-13. Additions to A-21, D-1, D-11, D-12, D-14.

[000120] Closed A-17, A-18, D-9, D-16. Additions to A-19. New issues A-20, A-21.

[000112] Closed A-15, A-16, D-2, D-3, D-8, D-15. Additions to A-17, A-18, D-9, D-11, D-13, D-14, D-16. New issue A-19 (split from A-17).

[000105] Closed D-0. Additions to D-1, D-9. New issues D-10 to D-16.

[000103] Additions to A-17.

[991230] Clarify definition of nearly empty class.

[991221] New issues A-15, A-16, A-17, A-18. Reopened C-3. Additions to C-3 (closed).

[991209] Additions to D-1, D-2, D-3. Closed D-4, D-7.

[991202] Additions to B-4 (closed), C-2, D-*. Closed B-1, C-1, C-3, G-3, G-6.

[991129] Additions to B-1, F-2, G-3. Closed B-5.

[991104] New issue G-6. Additions to C-4. Closed C-5, C-6, C-9.

[991028] Opened C-9, C-10. Closed A-6, B-6, C-10. Additions to C-5, C-6, F-1, F-2, F-3.

[991026] Additions to F-1.

[991012] Closed B-8, G-5. Additions to A-6, B-5, C-5.

[991012] Closed D-5, D-6. Additions to B-4, B-5, D-7.

[991005] New issue F-4. Additions to A-6, B-5, B-6, C-4, D-5, D-7.

[990929] Additions to D-*, D-9.

[990914] Additions to B-1, D-*, D-9.

[990908] New issue D-9. Additions to B-1, D-*, D-2, D-4, D-5, D-6.

[990901] Additions to A-6, B-6.

[990825] Additions to A-6, B-6, C-5, D-*.

[990813] Closed A-11. Additions to A-6, B-1, B-6, B-8, C-2, G-5.

[990810] New issue G-5. Additions to B-6, C-2, C-3.

[990805] Closed A-12, A-14, B-3, B-4, B-7, C-7. Additions to A-6, A-11, B-1, B-6, F-1.

[990729] Closed A-7. Additions to A-11, A-12, C-2. Summary added for A-12. New issue A-14.

[990727] Closed B-2, C-8. Additions to A-9 (closed), C-2. Summaries added for C-4, C-6, D-1 to D-4.

[990720] Additions to B-2, B-5, C-2, D-1.

[990701] Closed A-3, A-5, A-10, A-13. Additions to A-6, B-6, B-7, B-8, C-2, C-7.

[990625] 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.

[990616] 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.