This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: g++ and aliasing bools
- From: Daniel Berlin <dan at dberlin dot org>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Joe Buck <jbuck at synopsys dot COM>, Neil Booth <neil at daikokuya dot demon dot co dot uk>, Paolo Carlini <pcarlini at unitus dot it>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 28 Jan 2002 20:39:54 -0500 (EST)
- Subject: 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