<div dir="auto"><div><div class="gmail_extra"><div class="gmail_quote">On 24 Jan 2017 12:09 pm, "Vedant Kumar via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text"><br>
> On Jan 24, 2017, at 10:31 AM, Douwe Gelling <<a href="mailto:douwegelling@gmail.com">douwegelling@gmail.com</a>> wrote:<br>
><br>
> Ok, that makes sense. I wonder how g++ works around that problem..<br>
> 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>
> 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>
<br>
</div>There is an error for that (err_incomplete_typeid), but it doesn't look like it<br>
complains about taking the typeinfo of a pointer to an incomplete type. I think<br>
it makes sense to extend the error.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">No, it doesn't make any sense to add an error for valid code. Douwe, what problems are you having using type_info objects across translation units? It could be that there's a bug there (but at this point we don't have enough information to discount user error).</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
vedant<br>
<div class="elided-text"><br>
><br>
> 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>
> 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.<br>
><br>
> On Tue, Jan 24, 2017 at 6:39 AM, Douwe Gelling <<a href="mailto:douwegelling@gmail.com">douwegelling@gmail.com</a>> wrote:<br>
> I see, thanks for the explanation.. maybe some warning can be issued when this happens? It makes the typeinfo<br>
> of ptr to incomplete type basically useless in clang, whereas it works fine with other compilers<br>
> (gcc makes it weak external for example)<br>
><br>
> I feel it's a rather weird pitfall that will cause runtime errors and it's very easy to diagnose for compilers, though<br>
> there might be usecases I don't understand of course<br>
><br>
><br>
><br>
> On Mon, Jan 23, 2017 at 8:06 PM Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br>
> It looks like getTypeInfoLinkage (ItaniumCXXABI.cpp) can return 'linkonce_odr'<br>
> if SomeClass has a definition, and returns 'internal' otherwise. The rationale<br>
> is that type info for incomplete types must be kept separate from the type info<br>
> for complete types. IIUC we do this because inkonce_odr definitions can be used<br>
> by optimizations at any point, so the correct/full definition needs to be<br>
> available up front.<br>
><br>
> I'm CC'ing David since he wrote the comment, and can probably correct me if I<br>
> got this wrong.<br>
><br>
> best,<br>
> vedant<br>
><br>
> > On Jan 22, 2017, at 5:52 AM, Douwe Gelling <<a href="mailto:douwegelling@gmail.com">douwegelling@gmail.com</a>> wrote:<br>
> ><br>
> > I've reproduced it both on the system clang:<br>
> ><br>
> > Apple LLVM version 8.0.0 (clang-800.0.42.1)<br>
> ><br>
> > and on a newer clang installed with homebrew:<br>
> ><br>
> > clang version 3.9.1 (tags/RELEASE_391/final)<br>
> > Target: x86_64-apple-darwin16.3.0<br>
> ><br>
> > In llvm ir, it's marked internal constant with both compilers as well<br>
> ><br>
> > On Fri, Jan 20, 2017 at 6:23 PM Vedant Kumar <<a href="mailto:vsk@apple.com">vsk@apple.com</a>> wrote:<br>
> > What version of clang are you using?<br>
> ><br>
> > I tried referring to the typeid of SomeClass* from two different compilation<br>
> > units and ended up with just one copy of __ZTSP9SomeClass in my binary. The<br>
> > symbol is marked as 'linkonce_odr constant' in LLVM IR, which checks out.<br>
> ><br>
> > $ nm -m t | grep ZTSP9SomeClass<br>
> > 0000000100001f60 (__TEXT,__const) weak external __ZTSP9SomeClass<br>
> ><br>
> > best,<br>
> > vedant<br>
> ><br>
> > > On Jan 20, 2017, at 5:15 AM, Douwe Gelling via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> > ><br>
> > > Hi all,<br>
> > ><br>
> > > 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>
> > ><br>
> > > sample code:<br>
> > ><br>
> > > #include <typeinfo><br>
> > > #include <iostream><br>
> > > class SomeClass;<br>
> > ><br>
> > > int main()<br>
> > > {<br>
> > >   std::cout << typeid(SomeClass*).name() << std::endl;<br>
> > > }<br>
> > ><br>
> > > when running nm -m on the resulting binary, it contains:<br>
> > ><br>
> > > 0000000000000414 (__TEXT,__const) non-external __ZTSP9SomeClass<br>
> > ><br>
> > > ______________________________<wbr>_________________<br>
> > > cfe-dev mailing list<br>
> > > <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> > > <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
> ><br>
><br>
><br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</div></blockquote></div><br></div></div></div>