This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] ctor vtable vcall offsets
- To: Nathan Sidwell <nathan at codesourcery dot com>
- Subject: Re: [C++ PATCH] ctor vtable vcall offsets
- From: Jason Merrill <jason at redhat dot com>
- Date: 27 Feb 2001 14:57:04 +0000
- Cc: gcc-patches at gcc dot gnu dot org
- References: <3A9BAF18.28D33E46@codesourcery.com>
>>>>> "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