On 03/12/2012 03:09 PM, Lubos Lunak wrote:
Does this workaround for<http://llvm.org/bugs/show_bug.cgi?id=10113>
...should have been <http://llvm.org/bugs/show_bug.cgi?id=11250> "no code emitted for virtual inline function inherited indirectly from class template"
(where I'm still not convinced it is a user error vs. a compiler error)I am rather convinced that the original issue (without -fvisibility-inlines-hidden) is a user error, so I consider this to be a proper fix rather than a workaround. Imagine for example that the template has a static data member - that one would need to be merged to be just in one place, and that just wouldn't work if the template was public API but hidden.
I see no fundamental reason why that should not work. I would argue that the compiler could still export that symbol with some form of vague linkage, as it does if the template is not hidden. But I just see that GCC does not do that, and even somewhat specifies that it does not do that ("type visibility is applied to vague linkage entities associated with the class", <http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Type-Attributes.html#Type-Attributes> in combination with "Most everything in this section [on vague linkage] also applies to template instantiations" <http://gcc.gnu.org/onlinedocs/gcc-4.6.3/gcc/Vague-Linkage.html#Vague-Linkage>).
Looks like a misunderstanding whether hidden visibility is intended for "remove unnecessary entries from dynamic symbol tables (but keeping certain symbols exported to not violate certain standard requirements)" or "allow violations of ODR by hiding classes completely from dynamic symbol tables." I had naively assumed the former, while compiler writers apparently use the latter interpretation.
So in general I think templates need to be exported
I guess general reluctance against that insight in LO stems from LO being cross-platform, and the Windows dllimport/export model being substantially different from the GCC/ELF visibility model, and not marking (all-inline) templates for neither dllimport/export nor default visibility was the only approach that did work across all compilers, MSVC, GCC, and Sun. (If only worked sort of, see Michael's link to <http://web.archive.org/web/20100504161204/http://blogs.sun.com/GullFOSS/entry/why_some_compilers_suck_more>.)
(also look e.g. at STL headers, which export the entire std namespace,
Not sure what you mean here. At least with Fedora GCC 4.6, (all-inline) std class templates are not visibility-attributed (so would cause the problems discussed at <http://llvm.org/bugs/show_bug.cgi?id=11250> if client code derived from them).
Stephan