http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58585
--- Comment #6 from Jan Hubicka <hubicka at ucw dot cz> --- > > Is there way how to keep track of the vtables w/o doing the walk based on > > fields instead of BINFO_BASEs? > > There should be. Your code change makes sense to me; a primary base will > always be at offset 0, and from the comment those are the only ones we want to > walk into. It does not fix the problem, unfortunately. This is what happens: 1) we call record_binfo, binfo points to TYPE_BINFO of C and type_binfo points to TYPE_BINFO of C 2) record_binfo calls itself on base of C (that is B). both binfo and type_binfo gets updated to base_binfo (that is of type B) because BINFO_OFFSET is 8 3) record_binfo calls itslf on base of B (that is A) this time BINOF_OFFSET is 0, so type_binfo ends up to be one of type B, but we want one of type A. So in short the problem is that binfos represent the hiearchy C | B | A but only A and C have offset 0 (within C). Walking fields represents a hiearchy C / \ A B | A I tried to modify the code to always keep type_binfo to be the binfo of the type walked, but that does not work always either. (it fails when one has multiple inheritance and the second base has another base) I think only way to retrieve BINFO with vtable I want to walk is to walk up in the recursion chain and look if there is already BINFO with identical offset I am seeing. This is bit unhandy (one would have to manage the whole recursion stack of binfos) and may be easier to just immitate what get_binfo_at_offset does... I may be missing something obvious...