On Jun 27, 2012, at 10:24 AM, Rafael Espíndola wrote: > The tests in pr13124 shows a case where both gcc 4.7 and clang produce > an undefined reference to a destructor that we currently output (in > another TU) as linkonce_odr. > > This works 99.9% of the time because we output a strong vtable that > references that destructor, preventing any of the existing > optimizations from dropping it, but there is no guarantee that that > cannot happen. For example, function merging could merge that > destructor with another one since they are unnamed_addr. > > This also causes problems when globalopt marks linkonce_odr > unnamed_addr functions hidden and we are using the symbol across > shared libraries. > > The attached patch ensures that we produce a strong symbol for > functions that go in an strong vtable. This in turn ensure that it is > safe to output those vtables as available_externally in other TUs (and > use clang compiled libraries with gcc 4.7 compiled programs).
You did not attach a patch, but that's okay, because the behavior it implements is illegal as described. We cannot emit a strong symbol for something that can emitted as a weak symbol in another translation unit; I know that the linux linker is quite permissive about this, but (e.g.) the Darwin linker is not, and I would expect that even the Linux linker is generally not going to do The Right Thing with COMDAT. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
