Re: c++/6830: Virtual table layout: wrong vcall/vbase order for primary base class

[Nathan Sidwell <nathan at codesourcery dot com>]

The following reply was made to PR c++/6830; it has been noted by GNATS.

From: Nathan Sidwell <nathan@codesourcery.com>
To: Grigory_Zagorodnev@vniief.ims.intel.com, gcc-gnats@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nathan@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Cc:  
Subject: Re: c++/6830: Virtual table layout: wrong vcall/vbase order for primary 
 base class
Date: Wed, 03 Jul 2002 21:22:00 +0100

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6830
 
 not a bug. You are misinterpreting the ABI spec.
 
 (you do know about the -fdump-class-hierarchy flag don't you?) Anyway.
 The V::g thunk in S's vtable uses a vcall offset that you should consider
 part of S's vtable (not P's, the overridden class). So the vcall offset
 is at a lower index than the vbase offsets.
 
 This is the bit from 2.5.2 in the ABI (my emphasis)
 	Virtual call (vcall) offsets are used to perform ... These entries are
 	allocated in the virtual table for the *virtual* base class that is *most
 	immediately derived* from the base class containing the overridden.
 
 Here the most immediately derived virtual base on the path from P->S->V is S.
 The (ia32) vtable for V is and should be
 12	vbase offset V to R
 4	vbase offset V to S
 0	offset to top
 TI	type info
 .... primary vptr here
 v::g	final overrider
 ... start of secondary vtable (that for S)
 -4	vcall offset (to V) for V::g thunk
 8	vbase offset S to R
 -4	offset to top
 TI	type info
 vthunk(-4) to V::g
 
 nathan
 
 -- 
 Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org