Now with the patch.
On 27 June 2012 13:24, Rafael Espíndola <[email protected]> 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). > > Cheers, > Rafael
t.patch
Description: Binary data
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
