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