[cfe-commits] r110192 - in /cfe/trunk: lib/CodeGen/CGRTTI.cpp lib/CodeGen/CGVTables.cpp lib/CodeGen/CodeGenModule.cpp lib/CodeGen/CodeGenModule.h test/CodeGenCXX/exceptions-no-rtti.cpp test/CodeGenCXX/rtti-fundamental.cpp test/CodeGenCXX/rtti-linkage.cpp test/CodeGenCXX/vtable-linkage.cpp test/SemaCXX/typeid-ref.cpp

Nick Kledzik kledzik at apple.com
Wed Aug 4 11:02:34 PDT 2010


On Aug 4, 2010, at 9:55 AM, Chris Lattner wrote:
> On Aug 4, 2010, at 1:34 AM, John McCall wrote:
>
>> Author: rjmccall
>> Date: Wed Aug  4 03:34:44 2010
>> New Revision: 110192
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=110192&view=rev
>> Log:
>> Emit standard-library RTTI with external linkage, not weak_odr.
>>
>> Apply hidden visibility to most RTTI;  libstdc++ does not rely on  
>> exact
>> pointer equality for the type info (just the type info names).  Apply
>> the same optimization to RTTI that we do to vtables.
>
> Are you sure about that John?  I could have sworn that libstdc++  
> does pointer equality checks, guarded by a macro, which is enabled  
> in the darwin libstdc++.

My understanding in that there are to pieces of rtti data: the type  
info object, and the type info name.  And, the type info object  
contains a pointer to the type info name. The rtti runtime compares  
the "name" pointer in type info objects for the object equality test  
(operator==).   So, what John is doing seems to me like it should work.

What I don't know is if there are any compatibility issues.  That is,  
if there are some clients that depend on the type info object being  
defined in another dylib and then if that dylib is rebuilt with a  
compiler that has this change, then it won't export the type info  
object any more.

-Nick




More information about the cfe-commits mailing list