From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1660 invoked by alias); 29 Jan 2002 01:40:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1625 invoked from network); 29 Jan 2002 01:40:18 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 29 Jan 2002 01:40:18 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g0T1dsn20957; Mon, 28 Jan 2002 20:39:54 -0500 Date: Mon, 28 Jan 2002 21:55:00 -0000 From: Daniel Berlin To: Mark Mitchell cc: Joe Buck , Neil Booth , Paolo Carlini , "gcc@gcc.gnu.org" Subject: Re: g++ and aliasing bools In-Reply-To: <6490000.1012267669@warlock.codesourcery.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-01/txt/msg01857.txt.bz2 Message-ID: <20020128215500.ldU-zS2V86pqqkgkC_plzYfKEpzNf62G9p_rn5X003I@z> On Mon, 28 Jan 2002, Mark Mitchell wrote: > > > --On Monday, January 28, 2002 05:11:02 PM -0800 Joe Buck > 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 (, get_alias_set (BINFO_TYPE (binfo))); } } Ought to do it. --Dan