[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

John McCall rjmccall at apple.com
Wed Aug 4 13:25:05 PDT 2010

On Aug 4, 2010, at 11:02 AM, Nick Kledzik wrote:

> 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.

That was my thinking.

> 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.


More information about the cfe-commits mailing list