On Feb 15, 2013, at 4:54 PM, Richard Smith <rich...@metafoo.co.uk> wrote: > On Fri, Feb 15, 2013 at 4:34 PM, John McCall <rjmcc...@apple.com> wrote: > On Feb 14, 2013, at 8:07 PM, Richard Smith <rich...@metafoo.co.uk> wrote: > > If a class template specialization has an explicit instantiation > > declaration and needs a VTT, we currently emit all the vtable data as > > linkonce_odr. That causes link failures in some cases, because recent g++ > > versions put all the vtable-related data in a COMDAT, and if we emit some > > of the symbols but not all of them, we can cause the COMDAT from the > > explicit instantiation definition to not be chosen, resulting in missing > > symbols. > > > > This patch fixes that and removes some FIXMEs by switching us to > > available_externally. However, testing that fix revealed another problem: > > if (through inlining and constant propagation through the VTT) we end up > > with a reference to a construction vtable in the generated code, we will > > sometimes have no definition for that construction vtable. This is because > > the Itanium ABI does not require a compiler to emit construction vtables > > with any particular mangling or linkage, and indeed recent versions of > > libstdc++.so make all the construction vtable symbols internal. > > > > So this patch makes two changes: > > 1) Emit externally-available primary vtables and VTTs as > > available_externally rather than linkonce_odr, and > > 2) Emit externally-available construction vtables as internal rather than > > linkonce_odr. > > > > I believe point (2) conforms to the ABI -- while we're required to use the > > same primary vtable for all objects of the same most-derived type, the same > > restriction does not appear to apply to construction vtables. > > Er, I don't remember (and can't find) a requirement that all objects of the > same most-derived type must use the same non-construction virtual table > group, and I can't think of what would rely on that guarantee. That would > invalidate a number of optimizations we do, e.g. the optimization where we > give linkonce_odr v-tables and RTTI objects (but not RTTI names) hidden > visibility. > > I was referring to Itanium ABI, 2.5.1, first paragraph: "There may be > multiple virtual tables for a particular class, if it is used as a base class > for other classes. However, the virtual table pointers within all the objects > (instances) of a particular most-derived class point to the same set of > virtual tables."
Hmm, missed that. I'll send mail to cxx-abi-dev about removing that "requirement". John.
_______________________________________________ cfe-commits mailing list cfe-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
