tejohnson added a comment. In D96919#2575037 <https://reviews.llvm.org/D96919#2575037>, @davidxl wrote:
> So in this case, the virtual call in user code is resolved to a strong > definition in the shared library even though user code also has a derived > class defined? In other words, the library provides another overrider > definition as the final overrider? Yes. There is already support via LTO and the linkers to be conservative when a vtable is defined in a shared library. But without the type metadata on the available_externally vtables, LTO doesn't even know that the derived class vtable is related to the base class vtable from the shared library. So we erroneously think that there is only one possible implementation of the virtual method. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D96919/new/ https://reviews.llvm.org/D96919 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
