This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Fix backwards compatibility problem in libstdc++
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Paolo Carlini <pcarlini at suse dot de>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Mon, 16 Oct 2006 05:22:33 -0400
- Subject: Re: [PATCH] Fix backwards compatibility problem in libstdc++
- References: <20061013165326.GN20982@devserv.devel.redhat.com> <45301F53.9050101@suse.de>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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.
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.
Jakub