Re: PROPOSAL: duplicate elimination. 991026.3

[Jason Merrill <jason at redhat dot com>]

>>>>> "David" == David B Anderson <davea@quasar.engr.sgi.com> writes:

Sorry I didn't read over this the last time you sent it out.  A few
comments:

> ===================================================<3.3.8.3 wording>
> Part of this proposal  is that 2. at the end of section 3.3.8.3
> "Out-of-Line Instances of Inline Subroutines" 
> have its wording changed to:

> 2. The root entry for a concrete out-of-line-instance tree
> is normally owned by the same parent entry that also owns
> the root entry of the associated abstract instance.
> The parent may be different if the concrete out-of-line-instance
> or the abstract root, or both, are in Section Groups,
> as without this allowance some kinds of duplicate elimination
> would not be possible. 

I thought I had requested that we just remove the restriction entirely.  I
don't see any reason to prohibit, say, having the abstract instance inside
a class DIE and the concrete instance at file scope, either.

-------

I would also like to add this change:

  5.5.1 General Structure Description
...
       For C and C++, an incomplete structure, union or class  type
       is  represented  by  a  structure, union or class entry that
       does  not  have  a  byte  size  attribute  and  that  has  a
       DW_AT_declaration attribute.

+      A structure, union or class type that is declared as incomplete
+      before its later definition can be represented by a declaration entry
+      as described above, followed by another entry with a
+      DW_AT_specificiation attribute.  The value of this attribute is
+      a reference to the previous entry.

This is useful for nested classes which are defined outside of their
containing class definition, as in:

struct A {
  struct B;
};

struct A::B { };

If the two definitions are in different files, I would like to put them in
different CUs.

> 3.8.5 Example 2, C
...
I disagree with the use of DW_TAG_subunit here, see below.

> 3.8.7 DW_TAG_subunit and DW_TAG_compile_unit

> A Section Group compilation unit using DW_TAG_compile_unit is like any
> other compilation unit, in that it's contents would be evaluated by
> consumers as it it were an ordinary compilation unit.

Yes.

> Consider a #include within a C++ namespace declaration or within a
> function definition as examples where the DIEs in the Section Group
> should not be used independently of being referenced from elsewhere.
> They are not (necessarily) file-level entities.

I accept this rationale for DW_TAG_subunit (though I still don't think it's
necessary).

> Another example is #include in C, as there is no notion of a 'global'
> namespace for the types in C.

I disagree with this one.  We put types immediately under the CU when we
only use one CU for a compilation; why does dividing it up require us to
hide them?  It seems to me that your second example should use two
TAG_compile_units, and use DW_TAG_import_subunit to tell the debugger that
the two CUs are related, so that we look there first for a definition of A.

> 3.8.12 gcc example
> [perhaps this should be in appendix, and just referenced.]
> gcc-specific rules, mentioned to try to make this clearer 

> This is with respect to what will likely be
> in gcc version 3.30 

3.0.

Jason