C++ PATCH for c++/43120 (wrong-code with covariant thunks)

[H.J. Lu]

On Fri, Jul 9, 2010 at 11:51 AM, Jason Merrill <jason@redhat.com> wrote:
> As previously discussed at
> http://gcc.gnu.org/ml/gcc-patches/2003-01/msg02157.html
> when we have a covariant override of a virtual function from a primary
> virtual base, we need to use the vcall offset for the 'this' adjustment even
> though we know that the base is primary and therefore doesn't need any
> adjustment.
>
> But the code implementing this wasn't quite right; it assumed that the
> non-virtual offset between the binfo being considered and the overrider was
> always what we wanted, which is incorrect if the binfo is a secondary base
> of the overrider.  In fact, the non-virtual offset we want is always zero,
> because we're always looking at a primary virtual base of binfo which is
> necessarily at offset zero.
>
> So that's 43120.patch, which I checked in the other day to fix the
> wrong-code bug.
>
> But I still didn't feel like I had a good handle on the the issue, and so I
> kept digging to figure out a model that satisfied me.  What I eventually
> realized was that the issue was with determining which class the vtable slot
> pertains to, which is the nearest definition that doesn't require a
> covariant thunk; definitions that require a covariant thunk in this slot
> will use a different slot when called through a pointer to their class.
>
> This refinement allows us to optimize our vtable layout a bit: in the new
> abi/covariant6.C the C vtable can refer to the (non-virtual) thunk for B
> rather than the (virtual) thunk for A.  And in inherit/covariant7.C, we
> don't need to initialize the vtable slot for c1-in-c3-in-c4-in-c6 because
> it's a lost primary; a call through a c3 object will use a different vtable
> slot.
>
> So that's 43120-take2.patch, which I'm going to check in now.  While this
> changes the vtable contents, it does not change the ABI; it doesn't change
> the set of thunks emitted for a function, it just changes some slots to
> refer to a different member of that set, or none.
>
> Tested x86_64-pc-linux-gnu, applied to trunk.
>

This caused:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45473


-- 
H.J.