<div dir="ltr">I'm curious - how did it come up as a problem in devirtualization?</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 4, 2016 at 7:33 AM, Piotr Padlewski via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">2016-06-04 4:07 GMT+02:00 John McCall via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><span>> On Jun 3, 2016, at 7:05 PM, John McCall via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> On Jun 3, 2016, at 8:43 AM, David Blaikie via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>> I assume there's a good reason we don't do this - but I can't quite figure it out off the top of my head.<br>
>><br>
>> Any thoughts?<br>
><br>
> The translation unit that emits the key function is required to emit the v-table symbol with as a strong definition with the type's visibility.  It is not required to emit visible symbols for any of the inline virtual functions.  It is, of course, required to emit those functions as part of emitting the v-table; but it doesn't have to provide symbols for them at all, because even if it were possible to take the address of a virtual member function in a comparable way, there is no way to take that address *via the v-table* and so the v-table's reference may be to its own implementation.  This is good because it allows virtual methods to be given hidden visibility by default; it also permits v-tables to contain specialized method implementations, e.g. methods that use a known most-derived class.<br>
<br>
</span>To be clear, your idea would be a reasonable guarantee to make in a revised C++ ABI; it's just that it's not guaranteed to work under the current one.<br>
</div></div><div><div><br>
John.<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra">This problem was pretty annoying when I was working on devirtualization. It would be cool to fix ABI to support that. </div><div class="gmail_extra"><br></div></div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>