Re: [PATCH] Improved folding of virtual calls (gimple and C++ review requested)

[Jason Merrill <jason at redhat dot com>]

On 04/23/2010 11:48 AM, Martin Jambor wrote:
> On Wed, Apr 21, 2010 at 08:48:26PM -0400, Jason Merrill wrote:

> > I don't really see this in the patch.  If the BINFOs have the wrong
> > offsets, that sounds like a front end bug...

Indeed, it seems that if we have a class with a primary base (that is, a 
base at offset 0 with which we share a vtable) which itself has a 
primary base--such as B, A_2 and A in otr-fold-2.C--we update 
BINFO_VIRTUALS in B and A_2-in-B but not in A-in-A2-in-B.  This seems 
like a bug in the front end, but I suppose nothing in the front end is 
looking at the list of virtuals in that BINFO.  Indeed, I see this 
comment in dfs_modify_vtables:

/* There's no need to modify the vtable for a non-virtual primary base; 
we're not going to use that vtable anyhow.  We do still need to do this 
for virtual primary bases, as they could become non-primary in a 
construction vtable.  */

> > Is this supposed to be testing whether CLASSTYPE_AS_BASE for the base class
> > is different from the class itself?  That's the effect I would expect, and
> > that's different from whether multiple inheritance is involved.

I was confused about this; the base field type is changed to be the 
normal type when class layout is done.

Your algorithm seems sound; as you mentioned, the BINFO_VIRTUALS for the 
derived class will be a superset of those for the primary base.  My only 
remaining concern is that this is assuming G++ layout rules; do other 
front ends use the BINFO system?

Jason