https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88335
--- Comment #15 from Jason Merrill <jason at redhat dot com> --- On 11/28/19 12:58 PM, jakub at gcc dot gnu.org wrote: > Now, the issues: > 1) (so far ignored); the standard says that classes where all virtual members > are immediate are still polymorphic, > but I guess for the ABI we don't want a vtable pointer there. So, I > think we want TYPE_POLYMORPHIC_P set on > those, but e.g. TYPE_CONTAINS_VPTR_P probably shouldn't be true for them; > do we want TYPE_REALLY_POLYMORPHIC_P or > similar for polymorphic types that contain at least one non-immediate > virtual function and thus need a vtable? We still need a vtable for typeinfo, so I think we don't need to worry about this. > 2) initially I thought I'd just always emit a direct call to the immediate > virtual method found by lookup and do the remapping of that during constexpr > call evaluation; unfortunately as the > v->S::bar () etc. calls show, we only want to do that if LOOKUP_NONVIRTUAL > wasn't set; unfortunately, when immediate > functions aren't in the binfo structures, DECL_VINDEX is error_mark_node and > so I think we need some hack how to > preserve the info that we are going to call a virtual consteval method; could > we e.g. abuse OBJ_TYPE_REF with > different arguments that would make it clear it is something different, or > new tree? We need to store the instance > on which it is called and the virtual consteval method originally chosen e.g. > to compare the type > 3) I'm afraid one can't use a lookup_member on the actual instance type, > because it could find all kinds of things, > static member functions, typedefs, data members etc. in derived classes, > where we actually are only interested in > in virtual methods. So, shall we use something like look_for_overrides > does, except with the fndecl from the > base rather than derived and of course don't do anything except return > the first found method (and ignore static member > functions rather than handling them)? Would it work to include them at the end of BINFO_VIRTUALS but omit them in build_vtbl_initializer? > 4) guess covariant returns need to be handled at the end too somehow Yep. Jason
