http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52188
Bug #: 52188 Summary: [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: jamb...@gcc.gnu.org, paolo.carl...@oracle.com Host: *-*-solaris2* Target: *-*-solaris2.* Build: *-*-solaris2.* As already discussed to some length in http://gcc.gnu.org/ml/gcc-patches/2012-01/msg01163.html the following patch 2011-07-18 Martin Jambor <mjam...@suse.cz> * ipa-prop.h: Include alloc-pool.h, all sorts of updates to general comments. (ipcp_values_pool): Declare. (ipcp_sources_pool): Likewise. [...] caused libstdc++.so symbol versioning to be broken on Solaris. Before the patch, when compiling locale-const.cc only contains references and definitions of _ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv.constprop.36 After the patch, the same source has references to _ZNSt19istreambuf_iteratorIcSt11char_traitsIcEEppEv The latter is matched by the linker map and exported at version GLIBCXX_3.4.15, which is effectively closed with the release of gcc 4.6 where the symbol wasn't present. To avoid breaking symbol versioning on Solaris, the question is what to do here: we obviously cannot export it at 3.4.15, but could instead export it at 3.4.17 *on Solaris* instead. Before going that route, I need to make certain that this isn't just a code generation accident and the symbol can vanish again later: the exported interface of a shared object *must not* depend on the vagaries of code generation changes. Martin?