<div dir="ltr"><div><div>Ok, that makes sense. I wonder how g++ works around that problem..<br></div>Any chance of warning on taking the typeinfo of an incomplete type? It's only got limited use since you can't really use it across compilation units.<br></div>Just for some context: I ran into this issue by storing a pointer to incomplete type in a boost::any, and I assume the same issue would arise with std::any<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 24, 2017 at 6:43 PM David Majnemer <<a href="mailto:david.majnemer@gmail.com">david.majnemer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg">The reason why they cannot be combined is that "SomeClass" may have bases. The typeinfo for the incomplete type cannot know which bases the type might have while other translation units may know. We want to make sure that the typeinfo for a complete type doesn't get replaced with the incomplete type information, this is important to ensure that things like dynamic_cast work.</div><div class="gmail_extra gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg">On Tue, Jan 24, 2017 at 6:39 AM, Douwe Gelling <span dir="ltr" class="gmail_msg"><<a href="mailto:douwegelling@gmail.com" class="gmail_msg" target="_blank">douwegelling@gmail.com</a>></span> wrote:<br class="gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">I see, thanks for the explanation.. maybe some warning can be issued when this happens? It makes the typeinfo <br class="gmail_msg">of ptr to incomplete type basically useless in clang, whereas it works fine with other compilers <br class="gmail_msg">(gcc makes it weak external for example)<br class="gmail_msg"></div><br class="gmail_msg"></div>I feel it's a rather weird pitfall that will cause runtime errors and it's very easy to diagnose for compilers, though<br class="gmail_msg"></div>there might be usecases I don't understand of course<br class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"></div></div><div class="m_7270172612234997329HOEnZb gmail_msg"><div class="m_7270172612234997329h5 gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Jan 23, 2017 at 8:06 PM Vedant Kumar <<a href="mailto:vsk@apple.com" class="gmail_msg" target="_blank">vsk@apple.com</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It looks like getTypeInfoLinkage (ItaniumCXXABI.cpp) can return 'linkonce_odr'<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
if SomeClass has a definition, and returns 'internal' otherwise. The rationale<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
is that type info for incomplete types must be kept separate from the type info<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
for complete types. IIUC we do this because inkonce_odr definitions can be used<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
by optimizations at any point, so the correct/full definition needs to be<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
available up front.<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
I'm CC'ing David since he wrote the comment, and can probably correct me if I<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
got this wrong.<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
best,<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
vedant<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> On Jan 22, 2017, at 5:52 AM, Douwe Gelling <<a href="mailto:douwegelling@gmail.com" class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg" target="_blank">douwegelling@gmail.com</a>> wrote:<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> I've reproduced it both on the system clang:<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> Apple LLVM version 8.0.0 (clang-800.0.42.1)<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> and on a newer clang installed with homebrew:<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> clang version 3.9.1 (tags/RELEASE_391/final)<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> Target: x86_64-apple-darwin16.3.0<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> In llvm ir, it's marked internal constant with both compilers as well<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> On Fri, Jan 20, 2017 at 6:23 PM Vedant Kumar <<a href="mailto:vsk@apple.com" class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg" target="_blank">vsk@apple.com</a>> wrote:<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> What version of clang are you using?<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> I tried referring to the typeid of SomeClass* from two different compilation<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> units and ended up with just one copy of __ZTSP9SomeClass in my binary. The<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> symbol is marked as 'linkonce_odr constant' in LLVM IR, which checks out.<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> $ nm -m t | grep ZTSP9SomeClass<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> 0000000100001f60 (__TEXT,__const) weak external __ZTSP9SomeClass<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> best,<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> vedant<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > On Jan 20, 2017, at 5:15 AM, Douwe Gelling via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> ><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > Hi all,<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> ><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > When taking the typeinfo of a pointer to incomplete type, clang++ emits type info for the pointer in the resulting binary, but makes that typeinfo non-external (on osx at least). Is this intended? I'd have expected it to be weak external so that when the type is defined in other compilation units, the typeinfo isn't defined multiple times.<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> ><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > sample code:<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> ><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > #include <typeinfo><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > #include <iostream><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > class SomeClass;<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> ><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > int main()<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > {<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> >   std::cout << typeid(SomeClass*).name() << std::endl;<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > }<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> ><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > when running nm -m on the resulting binary, it contains:<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> ><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > 0000000000000414 (__TEXT,__const) non-external __ZTSP9SomeClass<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> ><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > _______________________________________________<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > cfe-dev mailing list<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > <a href="mailto:cfe-dev@lists.llvm.org" class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg" target="_blank">cfe-dev@lists.llvm.org</a><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
> > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
><br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
<br class="m_7270172612234997329m_3485848527759455702gmail_msg gmail_msg">
</blockquote></div>
</div></div></blockquote></div><br class="gmail_msg"></div>
</blockquote></div>