This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: g++ and aliasing bools


On Mon, 28 Jan 2002, Mark Mitchell wrote:

> 
> 
> --On Monday, January 28, 2002 05:11:02 PM -0800 Joe Buck 
> <jbuck@synopsys.COM> wrote:
> 
> >
> >> > The basic argument is this: I am allowed to implement C++ in a way that
> >> > zero-sized classes don't exist (they always come out as at least one
> >> > byte).  For such implementations I can clearly use the C rules, as
> >> > there is an equivalent C program.  If I then replace the inefficient
> >>
> >> [Implicitly, we're still in the simple_enough case here, i.e., no
> >> virtuals, etc.  Perhaps the argument applies more generally, but we
> >> don't know yet.]
> >
> >> OK, you've convinced me to extend simple_enough to the cases with
> >> zero-sized thingies, so long as the other conditions still hold.
> >
> > We can handle inheritance as well if the zero-sized object is OK, since
> > the C translation is to make the base class look like a member of the
> > derived class.  This will allow us to do better on most STL iterators;
> > many are derived classes but they have no virtual functions.
> 
> I agree; single, non-virtual inheritance should be OK.  In fact, even
> multiple inheritance should be OK, as long as there is no virtual
> inheritance anywhere in the hierarchy.
> 
> Once we introduce vtables, more complicated things can happen.  (We
> have to make sure that the vptr fields are in the same alias set.
> We may already do this; I remember fixing some problem like this
> at some point.)  If we have virtual bases, things are very complex;
> layouts are semi-dynamic.  It may be that it "just works", but I
> will continue to play devil's advocate.  You can continu to make
> persusasive arguments for safety. :-)
> 
> I remember another problem with base classes: they don't appear in
> the list of FIELDS on the class.  (The FIELD_DECLS are made and then
> thrown away since they are no longer needed.)

>  Therefore, the stock
> back-end record_component_aliases stuff won't work.  (This is not
> an algorithmic issue, like the ones we've been discussing before;
> this is a nitty-gritty here-we-are-in-GCC sort of thing.)

However, nowadays, the tree field you need isn't only part of the C++ 
frontend (IE it's common to tree.h).

Something like:

 /* Recursively record aliases for the base classes, if there are any */
    if (TYPE_BINFO_BASETYPES (t) != NULL)
      {
        for (i = 0; i < TREE_VEC_LENGTH (TYPE_BINFO_BASETYPES (t)); i++)
        {
          binfo = TREE_VEC_ELT (TYPE_BINFO_BASETYPES (t), i);
          record_alias_subset (<whatever>, get_alias_set (BINFO_TYPE (binfo)));
        }
      }
Ought to do it.

--Dan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]