[cfe-dev] Marking v-tables used whenever any virtual function is referenced
dgregor at apple.com
Mon Jul 16 09:34:42 PDT 2012
On Jul 15, 2012, at 7:37 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
>> That one fails for me without the patch:
> Yes, sorry, I was testing with an older version of clang.
>> error: 'error' diagnostics seen but not expected:
>> Line 90: implicit instantiation of undefined member
>> error: 'note' diagnostics seen but not expected:
>> Line 96: in instantiation of member function
>> requested here
>> Line 107: in instantiation of member function
>> 'LazilyInstantiate::A<int>::~A' requested here
>> Line 94: member is declared here
>> 4 errors generated.
>> We instantiate A<int>::F because it's used in C's vtable, which is used in
>> C's constructor, and that leads to us instantiate A<int>'s vtable, which
>> leads to us instantiate A<int>'s destructor, which fails. This test started
>> failing as a result of r159895; prior to that, we weren't instantiating
>> A<int>::F when building C's vtable. Is it possible you don't have that
> The only potential problem I see with this patch is making it a bit
> harder to fix pr13227, but we can worry about that when we get there.
> Dgregor, any opinions on this?
It seems like a step backwards. We're allowed to instantiate those virtual functions, and we want them instantiated so that we can inline calls to them after devirtualization kicks in. Introducing this patch is likely to eliminate some of those optimization opportunities, with the mild benefit of allowing Richard's dubious [*] example to continue working. It seems extremely likely that, when we dig further into devirtualization, we'd end up breaking Richard's example yet again. I'd rather that we break the example now rather than having to break it again later or (worse) constraining our ability to optimize later by committing to accepting this code.
[*] Dubious == it's undefined whether the example is well-formed or not.
More information about the cfe-dev