Re: [PATCH] Fix backwards compatibility problem in libstdc++

[Paolo Carlini <pcarlini at suse dot de>]

Hi Jakub,

> On Sat, Oct 14, 2006 at 01:20:51AM +0200, Paolo Carlini wrote:
>  
>
> > Jakub Jelinek wrote:
> >
> >    
> >
> > > The problem is if some 3.4.x program/library has an inlined copy of
> > > _S_construct or _M_clone
> > >
> > >      
> > By the way, only for my own education, I would be interested in knowing 
> > the specific circumstances when this happened: I tried relatively hard 
> > to convince the inliner to do that, but didn't succeed, I suspect rather 
> > extreme inline-limits are necessary... or?
> >    
> http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210452
>
> The inlining of _S_construct and not inlining of _S_create is in
> gcc 3.4.x compiled libboost_regex.a(c_regex_traits.o).  I haven't compiled
> that one myself to see exactly why one was inlined and the other was not,
> but the inliner certainly has the right to do so if it thinks it is a win.
>  
To be clear: I'm not saying that, at the time, we carefully pondered 
this possibility, I didn't at least, my bad. Only, I'm having trouble 
reproducing the problem with small snippets. Probably the fact that 
_S_construct is static is essential (I'm seeing static functions often 
inlined even when not marked as such) together with the fact that the 
caller of _S_contruct is out of line, yet tiny. Likely -O3 may have 
sufficed, at least on some arches.

> As the bugreport claims, this was originally reproduced with vanilla
> 3.4.6 compiled libboost_regex.so and can be also reproduced with
> 3.4.x-RH compiled libboost_regex.a.
>  
Ok. As I said already, for the moment the best way to go is your patch, 
which definitely doesn't impact the performance.

Paolo.