This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [C++ PATCH] ctor vtable vcall offsets


>>>>> "Nathan" == Nathan Sidwell <nathan@codesourcery.com> writes:

> +       else if (vid.ctor_vtbl_p && BV_VCALL_INDEX (v))
> +         {
> +           /* In the original, we did not need to use the vcall index, even
> +              though there was one, but in a ctor vtable things might be
> +              different (a primary virtual base might have moved). Be
> +              conservative and use a vcall adjusting thunk.  */
> + 	  vcall_index = BV_VCALL_INDEX (v);
> +           generate_with_vtable_p = 1;
> +         }

I haven't puzzled out all of the code, but it seems to me that we're
generating too many thunks with the vtable, here and in
update_vtable_entry_for_fn.  If we override a function from a virtual base,
we should emit a vcall thunk with the function definition whether or not we
plan to use it in our own vtable.

Actually, I don't see why we ever need to emit thunks with the vtable.  The
example in the ABI document is

  struct A { virtual void f(); };
  struct B : virtual public A { int i; };
  struct C : virtual public A { int j; };
  struct D : public B, public C {};

But here, calling A::f() means converting to A* then calling through the A
vtable, so the entry in the C vtable is never used.

What am I missing?

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]