This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Martin Jambor <mjambor at suse dot cz>, Richard Guenther <rguenther at suse dot de>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 19 Apr 2011 09:07:35 +0200
- Subject: Re: [PATCH] Fix incorrect devirtualization (PR middle-end/48661)
- References: <20110418214008.GE17079@tyan-ft48-01.lab.bos.redhat.com> <4DACBC2E.3000304@redhat.com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Apr 18, 2011 at 03:33:18PM -0700, Jason Merrill wrote:
> On 04/18/2011 02:40 PM, Jakub Jelinek wrote:
> >If TREE_BINFO has BV_VCALL_INDEX set, this needs to be dynamically
> >adjusted, but none of the callers are prepared to handle that.
>
> Well, it means that we do dynamic adjustment at runtime. If we're
> able to do devirtualization, we should be able to figure out the
> right offset as well, just not in 4.6.
Sure, but how exactly? If BV_VCALL_INDEX is non-NULL,
I guess we need to find for the given binfo corresponding rtti_binfo
that was (or would be if vtable isn't emitted in the current TU)
used in build_rtti_vtbl_entries to compute the difference between
BINFO_OFFSETs:
offset = size_diffop_loc (input_location,
BINFO_OFFSET (vid->rtti_binfo), BINFO_OFFSET (b));
That is the value actually added on top of the fixed delta, right?
Or do you think it should just add to the delta the value read from the
vcall_offset from the vtable?
But first of all PR48674 needs solving on the trunk.
I think cgraph thunk nodes have fixed_offset field so it is easy to figure
out that adjustment, but for vcall_offset adjustment the same applies here,
is there a way to find out what value will be added, or does it need to be
dynamic? And what kind of info do we need to find that out.
Jakub