Bug 12919 - icf fails to fold one of the component of std::sort
Summary: icf fails to fold one of the component of std::sort
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.21
: P2 normal
Target Milestone: ---
Assignee: Sriraman Tallam
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-22 08:07 UTC by Vincenzo Innocente
Modified: 2011-10-17 07:45 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vincenzo Innocente 2011-06-22 08:07:02 UTC
in this simple example below compiled with
 c++ -O2 -Wl,--icf=all,--print-icf-sections -shared -fPIC -fvisibility-inlines-hidden -ffunction-sections ICFproblem.cpp -o libbha.so
This function does not get folded
void std::__introsort_loop<__gnu_cxx::__normal_iterator<T**, std::vector<T*, std::allocator<T*> > >, long>(__gnu_cxx::__normal_iterator<T**, std::vector<T*, std::allocator<T*> > >, __gnu_cxx::__normal_iterator<T**, std::vector<T*, std::allocator<T*> > >, long)

details after the source code
I'm using
gcc version 4.6.1 20110520 (prerelease) (GCC) 
GNU gold (GNU Binutils 2.21.51.20110514) 1.11


cat ICFproblem.cpp 
#include<vector>
#include<algorithm>

struct A {
 A(float q=0): v(q){} 
 float v;
};
struct B { 
 B(float q=0): v(q){}
 float v;
};
struct C {
 C(double q=0): v(q){}
 double v;
};

std::vector<A*> ap;
std::vector<B*> bp;
std::vector<C*> cp;


void go() {
   std::sort(ap.begin(),ap.end());
   std::sort(bp.begin(),bp.end());
   std::sort(cp.begin(),cp.end());
}


 c++ -O2 -Wl,--icf=all,--print-icf-sections -shared -fPIC -fvisibility-inlines-hidden -ffunction-sections ICFproblem.cpp -o libbha.so
/afs/cern.ch/user/i/innocent/bin/ld: ICF Converged after 2 iteration(s)
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text._ZNSt6vectorIP1BSaIS1_EED2Ev' in file '/tmp/innocent/ccDpI7uD.o'into '.text._ZNSt6vectorIP1ASaIS1_EED2Ev' in file '/tmp/innocent/ccDpI7uD.o'
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text._ZNSt6vectorIP1CSaIS1_EED2Ev' in file '/tmp/innocent/ccDpI7uD.o'into '.text._ZNSt6vectorIP1ASaIS1_EED2Ev' in file '/tmp/innocent/ccDpI7uD.o'
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text._ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPP1BSt6vectorIS3_SaIS3_EEEEEvT_S9_' in file '/tmp/innocent/ccDpI7uD.o'into '.text._ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPP1ASt6vectorIS3_SaIS3_EEEEEvT_S9_' in file '/tmp/innocent/ccDpI7uD.o'
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text._ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPP1CSt6vectorIS3_SaIS3_EEEEEvT_S9_' in file '/tmp/innocent/ccDpI7uD.o'into '.text._ZSt16__insertion_sortIN9__gnu_cxx17__normal_iteratorIPP1ASt6vectorIS3_SaIS3_EEEEEvT_S9_' in file '/tmp/innocent/ccDpI7uD.o'
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text._ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPP1BSt6vectorIS3_SaIS3_EEEEEvT_S9_S9_' in file '/tmp/innocent/ccDpI7uD.o'into '.text._ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPP1ASt6vectorIS3_SaIS3_EEEEEvT_S9_S9_' in file '/tmp/innocent/ccDpI7uD.o'
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text._ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPP1CSt6vectorIS3_SaIS3_EEEEEvT_S9_S9_' in file '/tmp/innocent/ccDpI7uD.o'into '.text._ZSt19__move_median_firstIN9__gnu_cxx17__normal_iteratorIPP1ASt6vectorIS3_SaIS3_EEEEEvT_S9_S9_' in file '/tmp/innocent/ccDpI7uD.o'
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text._ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPP1BSt6vectorIS3_SaIS3_EEEElS3_EvT_T0_SA_T1_' in file '/tmp/innocent/ccDpI7uD.o'into '.text._ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPP1ASt6vectorIS3_SaIS3_EEEElS3_EvT_T0_SA_T1_' in file '/tmp/innocent/ccDpI7uD.o'
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text._ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPP1CSt6vectorIS3_SaIS3_EEEElS3_EvT_T0_SA_T1_' in file '/tmp/innocent/ccDpI7uD.o'into '.text._ZSt13__adjust_heapIN9__gnu_cxx17__normal_iteratorIPP1ASt6vectorIS3_SaIS3_EEEElS3_EvT_T0_SA_T1_' in file '/tmp/innocent/ccDpI7uD.o'
/afs/cern.ch/user/i/innocent/bin/ld: ICF folding section '.text' in file '/usr/lib/../lib64/crtn.o'into '.text' in file '/tmp/innocent/ccDpI7uD.o'
[vinavx0] ~/public/ctest $ nm -C libbha.so | sort | grep vector
00000000000010c0 W std::vector<A*, std::allocator<A*> >::~vector()
00000000000010c0 W std::vector<A*, std::allocator<A*> >::~vector()
00000000000010c0 W std::vector<B*, std::allocator<B*> >::~vector()
00000000000010c0 W std::vector<B*, std::allocator<B*> >::~vector()
00000000000010c0 W std::vector<C*, std::allocator<C*> >::~vector()
00000000000010c0 W std::vector<C*, std::allocator<C*> >::~vector()
00000000000010e0 W void std::__insertion_sort<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > > >(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >)
00000000000010e0 W void std::__insertion_sort<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > > >(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >)
00000000000010e0 W void std::__insertion_sort<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > > >(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >)
00000000000011b0 W void std::__move_median_first<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > > >(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >)
00000000000011b0 W void std::__move_median_first<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > > >(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >)
00000000000011b0 W void std::__move_median_first<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > > >(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >)
00000000000011f0 W void std::__adjust_heap<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long, A*>(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long, long, A*)
00000000000011f0 W void std::__adjust_heap<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long, B*>(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long, long, B*)
00000000000011f0 W void std::__adjust_heap<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long, C*>(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long, long, C*)
00000000000012e0 W void std::__introsort_loop<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long>(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long)
0000000000001430 W void std::__introsort_loop<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long>(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long)
0000000000001580 W void std::__introsort_loop<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long>(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long)
Comment 1 Vincenzo Innocente 2011-09-21 16:50:18 UTC
any news on a solution of this kind of problem?
Comment 2 Sriraman Tallam 2011-09-21 16:52:53 UTC
Sorry, I did not get a chance to look at this yet. I will take a look
at it this week.

Thanks,
-Sri.

On Wed, Sep 21, 2011 at 9:50 AM, vincenzo.innocente at cern dot ch
<sourceware-bugzilla@sourceware.org> wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12919
>
> --- Comment #1 from Vincenzo Innocente <vincenzo.innocente at cern dot ch> 2011-09-21 16:50:18 UTC ---
> any news on a solution of this kind of problem?
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
> You are the assignee for the bug.
>
Comment 3 Sriraman Tallam 2011-09-21 18:57:08 UTC
It is about pre-emptible symbols and libstdcxx makes namespace std as visiblity default.

It is working as intended. Let me explain with an example first.

If you have two functions foo and bar, calling zip and zap. If foo and bar are in a shared object and exported in the dynamic symbol table, it is not correct to fold foo and bar even though zip and zap get folded. Simple reason, zip and zap can be pre-empted by another definition in the executable. So, the ICF algorithm would only fold foo and bar if they both called functions with the same name. 

Here, the 3 introsort_loop functions essentially point to different move_median* functions (the functions differ in their names), for A, B and C. The move_median functions themselves get folded, but since they are exported,  icf thinks they can be pre-empted and in theory they can. So, it will not fold the introsort_loop functions.

However, if you were to link this into an executable, the introsort_loop functions would be folded.

However, pre-emption of these functions maybe never happens in practice. So, I could add a flag to icf that disables preemption and the introsort_loop functions would be folded. I am not sure if this is the right thing to do.
Comment 4 Sriraman Tallam 2011-09-21 18:58:03 UTC
It is about pre-emptible symbols and libstdcxx makes namespace std as visiblity default.

It is working as intended. Let me explain with an example first.

If you have two functions foo and bar, calling zip and zap. If foo and bar are in a shared object and exported in the dynamic symbol table, it is not correct to fold foo and bar even though zip and zap get folded. Simple reason, zip and zap can be pre-empted by another definition in the executable. So, the ICF algorithm would only fold foo and bar if they both called functions with the same name. 

Here, the 3 introsort_loop functions essentially point to different move_median* functions (the functions differ in their names), for A, B and C. The move_median functions themselves get folded, but since they are exported,  icf thinks they can be pre-empted and in theory they can. So, it will not fold the introsort_loop functions.

However, if you were to link this into an executable, the introsort_loop functions would be folded.

However, pre-emption of these functions maybe never happens in practice. So, I could add a flag to icf that disables preemption and the introsort_loop functions would be folded. I am not sure if this is the right thing to do.
Comment 5 Ian Lance Taylor 2011-09-21 19:55:58 UTC
I think you actually could combine functions within a .so.  Although the symbols are preemptible, if one of them is actually preempted, it will be done by redirecting the PLT entry.  So as long as you provide separate PLT entries for each symbol, you could arrange for all the PLT entries to point, by default, to the same code.
Comment 6 Vincenzo Innocente 2011-09-21 19:58:07 UTC
Thanks for the detailed analysis that indeed makes sense in the general case.
In this specific example introsort_loop is not inlined just for choice of a gcc
heuristics.
My understanding was that with -fvisibility-inlines-hidden I made the 3
move_median_first and the 3 introsort_loop functions "internals" to the library
and therefore neither visible nor preempt-able.
maybe they need to be declared "inline" in gcc or even "hidden"?
In any case I do not think that they are ment to be preempt-able!
Comment 7 Sriraman Tallam 2011-09-21 21:25:45 UTC
The std namespace is marked explicity with default visibility. So, these symbols are exported no matter what. If you do hide those symbols the folding will work.
Comment 8 Vincenzo Innocente 2011-09-22 08:13:26 UTC
I made few more tests:
adding inline keyword to __introsort in stl_algo.h makes no difference even if -fvisibility-inlines-hidden is used.

nm -C libbha.so | sort | grep introsort
0000000000002190 W void std::__introsort_loop<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long>(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long)
0000000000002a10 W void std::__introsort_loop<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long>(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long)
0000000000003290 W void std::__introsort_loop<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long>(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long)


what (with gcc 4.7, I think should be the same with 4.6.1) seems to work is -flto 
with "inline" added  the three introsort are now folded
 c++ -flto -O2 -Wl,--icf=all,--print-icf-sections -shared -fPIC -fvisibility-inlines-hidden -ffunction-sections ICFproblem.cpp -o libbha.so
nm -C libbha.so | sort | grep introsort
0000000000002210 t _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPP1ASt6vectorIS3_SaIS3_EEEElEvT_S9_T0_.local.43
0000000000002210 t _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPP1BSt6vectorIS3_SaIS3_EEEElEvT_S9_T0_.local.29
0000000000002210 t _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPP1CSt6vectorIS3_SaIS3_EEEElEvT_S9_T0_.local.15

funny enough w/o inline (original std_algo.h) there is just one symbol explicitly generated
 nm -C libbha.so | sort | grep introsort
00000000000009f0 t _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPP1CSt6vectorIS3_SaIS3_EEEElEvT_S9_T0_.local.15.2431
btw we need to make c++filt understanding "local" symbols :-( 
 echo  _ZSt16__introsort_loopIN9__gnu_cxx17__normal_iteratorIPP1CSt6vectorIS3_SaIS3_EEEElEvT_S9_T0_ | c++filt
void std::__introsort_loop<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long>(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long)

I will iterate with GCC folks on this.
In any case, I support Ian's proposal to have, for .so libraries, just independent PLT entries and fold the "internal" ones.
Comment 9 Vincenzo Innocente 2011-09-22 10:29:29 UTC
I tried to add __attribute__ ((visibility ("hidden"))) to __introsort_loop
no folding either even if now the symbol is "t" not "W".


c++ -O2 -Wl,--icf=all,--print-icf-sections -shared -fPIC -fvisibility-inlines-hidden -ffunction-sections ICFproblem.cpp -o libbha.so

nm -C libbha.so | grep intro
0000000000001fa0 t void std::__introsort_loop<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long>(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long)
0000000000002230 t void std::__introsort_loop<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long>(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long)
00000000000024c0 t void std::__introsort_loop<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long>(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long)
Comment 10 Sriraman Tallam 2011-09-22 17:48:57 UTC
On Thu, Sep 22, 2011 at 3:29 AM, vincenzo.innocente at cern dot ch
<sourceware-bugzilla@sourceware.org> wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=12919
>
> --- Comment #9 from Vincenzo Innocente <vincenzo.innocente at cern dot ch> 2011-09-22 10:29:29 UTC ---
> I tried to add __attribute__ ((visibility ("hidden"))) to __introsort_loop
> no folding either even if now the symbol is "t" not "W".

Isn't it the case that __introsort_loop has references to pre-emptible
functions like move_median*. So, it is important to make  the
referenced functions hidden than making introsort_loop itself hidden.
It does not matter that introsort_loop is hidden or not.

Now, it is the case that a hidden function in a shared object calls a
pre-emptible function, right? Which means, the behaviour of the hidden
function can still be changed by providing new definitions for the
pre-emptible functions.

>
>
> c++ -O2 -Wl,--icf=all,--print-icf-sections -shared -fPIC
> -fvisibility-inlines-hidden -ffunction-sections ICFproblem.cpp -o libbha.so
>
> nm -C libbha.so | grep intro
> 0000000000001fa0 t void std::__introsort_loop<__gnu_cxx::__normal_iterator<A**,
> std::vector<A*, std::allocator<A*> > >, long>(__gnu_cxx::__normal_iterator<A**,
> std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**,
> std::vector<A*, std::allocator<A*> > >, long)
> 0000000000002230 t void std::__introsort_loop<__gnu_cxx::__normal_iterator<B**,
> std::vector<B*, std::allocator<B*> > >, long>(__gnu_cxx::__normal_iterator<B**,
> std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**,
> std::vector<B*, std::allocator<B*> > >, long)
> 00000000000024c0 t void std::__introsort_loop<__gnu_cxx::__normal_iterator<C**,
> std::vector<C*, std::allocator<C*> > >, long>(__gnu_cxx::__normal_iterator<C**,
> std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**,
> std::vector<C*, std::allocator<C*> > >, long)
>
> --
> Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
> You are the assignee for the bug.
>
Comment 11 Vincenzo Innocente 2011-09-23 11:15:33 UTC
Indeed there is a long chain of function calls.
So I removed the visibility from the namespace in stl_algo.h

namespace std /* _GLIBCXX_VISIBILITY(default) */

and

c++ -O2 -Wl,--icf=all,--print-icf-sections -shared -fPIC -fvisibility-inlines-hidden -ffunction-sections ICFproblem.cpp -o libbha.so -fno-inline -fvisibility=hidden
no folding of the sorting stuff (even if now its all LOCAL  HIDDEN)

readelf -sW libbha.so | grep -v UND | c++filt | grep move_median 
     80: 00000000000043b0   149 FUNC    LOCAL  HIDDEN    11 void std::__move_median_first<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > > >(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >)
    89: 0000000000004d60   149 FUNC    LOCAL  HIDDEN    11 void std::__move_median_first<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > > >(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >)
    98: 00000000000056e0   149 FUNC    LOCAL  HIDDEN    11 void std::__move_median_first<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > > >(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >)
[vinavx0] ~/public/ctest $ readelf -sW libbha.so | grep -v UND | c++filt | grep introsort
    83: 0000000000004560   120 FUNC    LOCAL  HIDDEN    11 void std::__introsort_loop<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long>(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, long)
    92: 0000000000004f10   120 FUNC    LOCAL  HIDDEN    11 void std::__introsort_loop<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long>(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, long)
  101: 0000000000005890   120 FUNC    LOCAL  HIDDEN    11 void std::__introsort_loop<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long>(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, long)


p.s. made
void  __attribute__ ((visibility ("default"))) go() 
in ICFproblem.cpp
Comment 12 Vincenzo Innocente 2011-10-16 17:55:33 UTC
apparently one can configure gcc "--disable-visibility" that will essentially remove the default visibility
from namespace std w/o any other side-effect.

I tried and indeed now everything fold together nicely as you can see below.
I will continue to experiment with this option


00000000000013d0 t void std::__insertion_sort<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > > >(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >)
00000000000013d0 t void std::__insertion_sort<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > > >(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >)
00000000000013d0 t void std::__insertion_sort<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > > >(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >)
0000000000001480 t void std::__final_insertion_sort<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > > >(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >)
0000000000001480 t void std::__final_insertion_sort<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > > >(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >)
0000000000001480 t void std::__final_insertion_sort<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > > >(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >)
0000000000001510 t void std::__move_median_first<__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > > >(__gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >, __gnu_cxx::__normal_iterator<A**, std::vector<A*, std::allocator<A*> > >)
0000000000001510 t void std::__move_median_first<__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > > >(__gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >, __gnu_cxx::__normal_iterator<B**, std::vector<B*, std::allocator<B*> > >)
0000000000001510 t void std::__move_median_first<__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > > >(__gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >, __gnu_cxx::__normal_iterator<C**, std::vector<C*, std::allocator<C*> > >)
Comment 13 Vincenzo Innocente 2011-10-17 07:45:23 UTC
No action required on the gold side, was a visibility issue in gcc.