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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
