[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

[Chris Lattner]

On Aug 4, 2010, at 1:25 PM, John McCall wrote:
>> 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.
> 
> That was my thinking.

Ok!

>> 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.
> 
> The rule I implemented follows the same rules as weak vtables:  if there's a possibility that there might be external references that can only be resolved by this symbol, then we can't give it hidden visibility.  In concrete terms, we disable the optimization if the class has a key function or is an explicit instantiation.  In every other case, I believe the ABI requires every translation unit to emit the RTTI.
> 
> There are probably cases where this breaks compatibility in the presence of inconsistent -fno-rtti settings.

I think that the right answer is to be aggressive about this in clang, and earlier is better.  It's better for people to discover potential issues here when switching from other compilers to Clang than it is switching to some later version of it.

-Chris