g++ and aliasing bools

[Mark Mitchell]

--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.)

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com