http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252
--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> ---
We are getting an integer instead of an expected ADDR_EXPR to a
FUNCTIONN_DECL. Token is 3, known_binfo which is a binfo pertaining to
(gdb) pge known_binfo->typed.type
struct StructDef
has the following virtual methods (according to c++ front-end function
dump_binfo):
virtuals:
_ZN9POA_CORBA9StructDefD1Ev [0 =? 0]
_ZN9POA_CORBA9StructDefD0Ev [1 =? 1]
_ZN11omniServant15_ptrToInterfaceEPKc [2 =? 2]
One with index, zero, the other with 1, the third with 2. No function
with index 3 there. The constant we are loading from the initializer
is actually there right behind the address of the third method, so
that is correct. Moreover, the original OTR has 3 in it. The code
that actually loads the destination from the vptr also adds 24 bytes,
so it also jumps to the fourth function:
(gdb) up 8
(gdb) call debug_function (edge->caller->symbol.decl, 0)
...
D.3162 = impl->D.2424.D.2333._vptr.omniServant;
D.3163 = D.3162 + 24;
D.3164 = *D.3163;
D.3165 = tcd->arg_3;
D.3166 = tcd->arg_2;
D.3167 = tcd->arg_1;
D.3168 = tcd->arg_0;
D.3171 = OBJ_TYPE_REF(D.3164;impl->3) (impl, D.3168, D.3167, D.3166, D.3165);
When I look at what is the OTR recorderd in the edge I get
(gdb) pge edge->indirect_info->otr_type
struct _impl_Container
and its binfo has 4 virtual methods!:
(gdb) call debug_binfo(edge->indirect_info->otr_type->type_non_common.binfo)
...
virtuals:
_ZN5CORBA15_impl_ContainerD1Ev [0 =? 0]
_ZN5CORBA15_impl_ContainerD0Ev [1 =? 1]
_ZN11omniServant15_ptrToInterfaceEPKc [2 =? 2]
_ZN5CORBA15_impl_Container16create_exceptionEPKcS2_S2_RKNS_15StructMemberSeqE
[3 =? 3]
yet, in the 000i.type_inheritance dump, StructDef seems to be a
descendant of _impl_Container:
type 5: struct _impl_Container
defined at: a.cc:67
base odr type ids: 1
derived types:
type 6: struct _impl_StructDef
defined at: a.cc:75
base odr type ids: 4 5
derived types:
type 13: struct StructDef
defined at: a.cc:93
base odr type ids: 6 11 12
But that I would say is impossible, because it has fewer virtual
methods than its alleged ancestor. I would say it if was not clearly
obvious from the source that the dump file is correct. It seems that
because the fourth virtual function is never implemented in this part
of the hierarchy, it is simply omitted in the virtual table (and
BINFO_VIRTUALs).
I have no clue how to detect this in gimple_get_virt_method_for_binfo
other than gracefully ignore rubbish... and hope that there isn't an
address of a function in that rubbish... :-/
