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...