Agenda for Thursday

[Jim Dehnert]

Following is an updated agenda.  The status pages are updated and on
the web at:

	http://reality.sgi.com/dehnert_engr/cxx/cxx-summary.html

The contact info page is now also there, in password-protected PDF only
for privacy.  The password is "not an orc".

A reminder:  At the next two meetings, I'd like to clear away most of
the significant and solvable issues, as I'll be gone for the following
5 Thursdays, and several implementations are far enough along to need
resolution.  That means:

  - Please look over the open issues carefully, and try to sort out
    your ideas/position on them.  Raise issues/clarify things by email
    in advance if possible.

  - These next two weeks are a good time to not miss the meetings if
    you care about the issues.

  - I'd like to try real hard to start on time, and we might go
    overtime if things are moving.

  - Note that the number has changed from the last "real" meeting:
    it's now (650) 933-7952.  (In general, if you're not sure, it's on
    the contact page.)

Also, note that it doesn't usually work to try to contact me by email
or phone the morning of the meeting, as I come directly from home.  If
you come in physically to the meeting, and the receptionist won't let
you come back to the conference room on your own, have her call the
conference room (it has a phone other than the one we use for the
meeting).

As usual, most of the updates are in the ABI layout document, in color.
The significant changes from last time are:

 - Clarify ordering of vcall offsets.

 - Further elaboration of the construction vtable.

 - Specify COMDAT RTTI name (proposed resolution of A-28).

 - Derive pointer-to-member RTTI and pointer RTTI from common base.
   (Proposed resolution of A-29.)

 - Clarify substitution in mangled names by changing grammar approach.

 - Updates in Vague Linkage section.

Please take a careful look at the colored text, and raise any issues
you observe.  In particular, be prepared to list other things which
need to be mentioned in the new vague linkage section.

Take a look at the material associated with the following issues.
Many of them are issues we think we've resolved, and all that's missing
is final approval of the descriptions.  If you see something, please
send it by email, and it might get fixed before the meeting.

  1) C-2:  Priority for constructors.  The base ABI group is not
     particularly interested in this, because they are not getting
     pressure from their C++ people to worry about it.  So, if we want
     to standardize this, we need to apply pressure within our
     companies.

     We have three choices:

     - We can press ahead and try to build support for a common
       solution.

     - We can specify the API only (already done, and not strictly
       speaking an ABI issue) so that implementors at least provide a
       common source code mechanism.

     - We can specify nothing.

     I don't think we should pursue the first unless we have vendors
     anxious to support it.

  2) A-29:  pointer-to-member RTTI.  Proposed resolution and writeup OK?

  3) A-28:  incomplete class RTTI and equality testing.  Proposed
     resolution and writeup OK?

  4) C-4:  Construction vtables.  Ready to close?

  5) F-1:  Mangling template parameters.  Daveed has convinced me and
     Matt that this is much simpler than what we were trying to
     attempt.  Does anyone else have residual confusion?

  5) F-7:  Mangling statics.  Is writeup OK?

  6) F-11:  Hash for local strings.  Close with current (non-hash)
     writeup?

  7) F-2:  Mangled name size.  Our hope has been that the substitution
     mechanism will make further efforts unnecessary.  How do we go
     about validating this?  Martin's first data are excellent.
     Matt gave him another set of names to try -- any luck?

  8) F-3:  Mangling instantiation/specialization.
     F-4:  Empty throw specifications.
     F-10: Mangling return types.

     Coleen made a proposal for F-3.  Jim updated the SGI interface
     section to handle all three.  Where should we go with this?

     G-2:  ODR violations.  Is there anything we should be trying to
     address besides the above cases?  Can we close this one?

  9) F-6:  Demangler.  We have an updated proposal from Matt.  Is is
     OK?

 10) D-12:  Unwind table location.

     Unfortunately, though I'm not real happy with forcing the unwind
     tables into the text segment being described, and believe that we
     could avoid that restriction without significant complications,
     I think the current scheme is workable for mainstream systems, and
     I suspect that changing it at this point will encounter more
     resistance than we can overcome.  So without a groundswell of
     support for a more general scheme, we should probably close this
     with the current approach.  Comments?

 11) C-3:  Order of ctors/dtors w.r.t. DSOs.  Mark proposed a
     simplification a while back to what we had accepted.  It looks
     good to me.  Comments?

For next week, be prepared to discuss:

 12) G-4, C-14:  Specify form of local-scope single-initialization.

 13) E-*:  Do we go anywhere with templates?  Note that our mangling
     and vague linkage specifications should be sufficient to make
     instantiations play together -- the principal issue is whether to
     attempt to specify how to deal with instantiations that aren't
     produced when the reference occurs, i.e. export templates.

 14) H-*:  Do we go anywhere with the runtime library interface?
     I have been convinced that the extensive use of templates and
     associated helper functions probably makes it impractical in the
     short term to connect all but the simplest objects compiled with
     one vendor's header files with another vendor's libC.

     An intermediate model that might be more tractable is this:
     Suppose that one compiles objects with multiple vendors'
     compilers, but all with the header files for the target system.
     Then the key issue in making them work together will be whether
     the various non-Standard-Library interfaces used by the compilers
     (e.g. internal math functions or some such) play together.  If the
     ABI specifies that such runtime routines be named to avoid
     conflicts (e.g. __cxa_sgi_foo) and be placed in a library separate
     from libC so that each vendor's set could be linked into the end
     program, this seems doable.  Comments?

Jim

-		Jim Dehnert  x3-4272