libstdc++ abi-check failing on x86-linux
Geoff Keating
geoffk@geoffk.org
Mon Feb 25 02:22:00 GMT 2008
Between revision 132433 and 132439 (that is, 132433 was good, 132439
was not), the regression tester started to see
2 incompatible symbols
0
_ZSt13__check_facetISt7codecvtIcc11__mbstate_tEERKT_PS4_
std::codecvt<char, char, __mbstate_t> const&
std::__check_facet<std::codecvt<char, char, __mbstate_t>
>(std::codecvt<char, char, __mbstate_t> const*)
version status: incompatible
GLIBCXX_3.4
type: function
status: added
1
_ZSt13__check_facetISt7codecvtIwc11__mbstate_tEERKT_PS4_
std::codecvt<wchar_t, char, __mbstate_t> const&
std::__check_facet<std::codecvt<wchar_t, char, __mbstate_t>
>(std::codecvt<wchar_t, char, __mbstate_t> const*)
version status: incompatible
GLIBCXX_3.4
type: function
status: added
=== libstdc++-v3 check-abi Summary ===
# of added symbols: 134
# of missing symbols: 0
# of incompatible symbols: 2
using: baseline_symbols.txt
FAIL: abi_check
Now, there was only one change between these revisions, which was:
------------------------------------------------------------------------
r132439 | hubicka | 2008-02-19 09:09:42 -0800 (Tue, 19 Feb 2008) | 4
lines
PR middle-end/28779
* tree-inline.c (estimate_num_insns_1): Fix counting of cost of
call_expr.
------------------------------------------------------------------------
so I think what's happened is that inlining has changed and so this
function isn't inlined any more. It doesn't seem that simply not
inlining a function should cause testcase failures; is the ELF symbol
versioning especially fragile in the face of inlining changes?
More information about the Libstdc++
mailing list