Notes from the 14 October IA-64 C++ ABI meeting

[Matt Austern]

                              ISSUE B-5

Discussion: Jason suggests changing the name from SHT_COMDAT_GROUP to
SHT_GROUP.  The motivation is that these really aren't COMDAT sections
unless the SHF_COMDAT flag is set.  It's a grouping proposal, so the
name ought to have no connotations other than grouping.

There is a mild consensus in favor of this change, which is minor but
pervasive.  Nobody was opposed to it.  There is a consensus that we
recommend this change to the base ABI committee, but that we accept
whichever name they choose to adopt.

ACTION ITEM: Jim---push the proposal over to the base ABI committee,
telling them about our naming preference.  This issue is tabled, but
not closed.  We will revisit it after the base ABI committee acts.


                              ISSUE A-6

Discussion:

(1) Do we keep pointers to direct bases only, or to indirect bases as
well.  It is believed that keeping pointers to indirect bases speeds
up dynamic_cast by a constant factor, but at the cost of extra space
even when dynamic_cast is never used.  There is a general preference
for keeping direct bases only.

(2) The current proposal has a flag to differentiate single
inheritance from multiple inheritance case.  Jason suggests instead
splitting the two cases into two separate classes, and there was
general agreement that this is a good idea.

(3) The current proposal has separate classes for various kinds of
non-class types.  Jason suggests merging all non-class types into a
single class.  Nobody had strong feelings, or strong arguments either
for or against this change.  In the absence of a consensus in favor of
this change, we'll keep the proposal as is.

(4) Minor changes: there's a typo in the pointer to member part, which
Daveed will fix.  Jason suggests flipping the sign on the offset, and
nobody objected.

ACTION ITEMS: Daveed---make these changes.  Jim---incorporate these
changes into the open issues list.  We are almost ready to close this
issue; we intend to close it at the 28 October meeting, after we've
all had a change to go over the modified writeup.


                              ISSUE B-6

Discussion:

(1) Do we promote base offsets out of base class vtables?  Answer: we
promote them out of virtual bases, but we do not promote them out of
nonvirtual bases.  It's a time/space tradeoff.  The time saving is
large for virtual bases, but to small to bother with for nonvirtual
bases.

(2) Do we have rtti fields for classes that have virtual bases but no
virtual functions?  The C++ standard regards such classes as
nonpolymorphic, so performing rtti operations on them is undefined.
Decision: we will keep the rtti fields themselves in the vtable, in
the interest of having a uniform vtable format.  The slot of offset to
beginning of complete type will be filled in, and the slot for offset
to typeinfo object will contain 0.

(3) When we discussed issue B-8, we agreed that we would have an
offset to typeinfo object rather than a pointer to typeinfo object.
This means that the typeinfo object is now part of the vtable.  It
will go at the very beginning, i.e. at a negative offset from where
the vtpr points.  (Comment: We discussed B-6 before discussing B-8.
Does making this change interfere with having a uniform vtable offset,
since we won't have a typeinfo object at the beginning of a vtable
for a nonpolymorphic class with virtual bases?  Should we revisit
decision (2) or (3), or am I just being paranoid?)

ACTION ITEMS: Jason---update writeup to reflect these three changes.
Our decision on issue B-8 will require a one-sentence change.  All of
us: study the revised version.  We are almost ready to close this
issue, and if we agree with the revised version we can close it at the
21 October meeting.  (Yes, I really do mean the meeting when most of
us will be in Hawaii.)


                              ISSUE B-8

Discussion: This is closely related to issues A-6 and B-6.  It is
agreed that what we need is an offset to the beginning of the complete
object, and a pointer or offset to the typeinfo object.  We choose to
have an offset to the typeinfo object instead of a pointer, which
effectively means that the typeinfo object is part of the vtable.  We
will put it at the very beginning, at a negative offset from the vptr.

ACTION ITEMS: See B-6.

This issue is now closed.


                              ISSUE G-5

Discussion: We would want to reject option (3), even if it were still
possible to change the base ABI.  The present scheme is compatible
with K&R C methods, the proposed change would not be.

Decision: Close with no action.  We're using multiple entry points for
covariant return types, not thunks, so there's no need for doing
anything different for varargs functions with covariant return types
than for any other varargs functions.


                          ISSUES C-6 and C-6

Discussion: One solution to the problem with destructors is to have
two destructor entry points, and two destructor slots in the vtable.
One entry point destroys the object and then calls operator delete,
the other destroys the object without calling operator delete.  We can
use a similar solution for constructors (but without any impact on the
vtable layout): one entry point for constructing a complete object,
another for constructing a subobject.

Note that one of the entry points may call the other, but that's not
an ABI issue and can be left to individual implementors.

There was general agreement that this is a promising idea.  We don't
have a detailed proposal yet.  HP is working on a prototype
implementation.

Action item: Christophe---submit a writeup.