rjmccall at apple.com
Wed Jan 18 20:12:05 PST 2012
On Jan 18, 2012, at 6:38 PM, Howard Hinnant wrote:
> Thanks Eli. That is the context I was looking for. This looks more like a template-2-phase-lookup issue to me (where clang is doing a better job than gcc during template parsing).
The weasel wording about incomplete types within templates is actually separate, but tt's that general category of problem, yeah.
> In order to match the thrown object to a catch handler the personality function needs to read the std::type_info* out of the lsda table at the end of a procedure fragment. So the question becomes: what does the compiler encode for a std::type_info* for an incomplete class type? I haven't found a way to entice the compiler to reveal that except in the case of clang and in the case of the incomplete type in the catch clause. For example typeid(A) enforces a complete type A.
The Itanium ABI tells us to generate a weak (in both the "dynamically replaceable" and "coalesced by the linker" senses) object of type __class_type_info. It has to be linker-coalesced because there's no way for translation units to agree on who should emit it; it has to be dynamically replaceable so that RTTI emitted by translation units with the class definition available will replace it. Of course, there's no guarantee that the "defining" translation units will emit the RTTI at all, and even if they do, I'm not sure that static+dynamic linkers necessarily support all the crazy combinations of replacement that can happen here.
I am also willing to believe that Clang have bugs relating to that replacement.
More information about the cfe-dev