public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1
@ 2015-10-08 22:44 ylow at graphlab dot com
2015-10-09 8:09 ` [Bug libstdc++/67903] " rguenth at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: ylow at graphlab dot com @ 2015-10-08 22:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67903
Bug ID: 67903
Summary: std::locale compatibility between gcc4.9 and gcc5.1
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ylow at graphlab dot com
Target Milestone: ---
Created attachment 36466
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36466&action=edit
patch to locale.cc
This is a complex issue and is probably an artifact of how we are doing our
linking. In general, I am not entirely confident of my diagnosis and it is hard
to replicate in a smaller test case.
In our code, we statically link libstdc++ into our shared library since that
resolves a lot of issues with dynamic libstdc++ since a different (older)
libstdc++ may be loaded before us.
However, there is some kind of conflict in std::locale static initialization
when:
- There is a system libstdc++ from gcc 5.1 (i.e. a newer libstdc++)
which creates a lot more facets
- The system libstdc++ first (and initializes it)
- Then our shared library loads and the following occurs:
- std::locale::_S_initialize_once() is called again.
This is probably due to _S_once not being exported so
so every occurance of the libstdc++ initializes again.
- However, the local init implementation IS exported
- So the new init function is called,
- However, _S_global is NOT exported
- So the old object is used.
So to summarize,
- We have a repeat initialization of std::locale. Once in the new libstdc++
and once in the old libstdc++ (this is actually OK)
- However, the new locale function initialization is used always which
causes issues since in gcc 5.1, the locale has more stuff: It fills 46 locales
into _M_facets rather than 28.
This would not be a problem if not for the fact that:
- the global locale is initialized with an inplace new:
locale_init.cc:378
_M_facets = new (&facet_vec) const facet*[_M_facets_size];
_M_caches = new (&cache_vec) const facet*[_M_facets_size];
- the locale inserter (locale_init.cc:354) correctly checks when it should
extend the _M_facets, but happily just deletes the old array.
locale.cc:348
delete [] __oldf;
delete [] __oldc;
- which of course fails gloriously with the inplace new.
- The solution is to actually do the resize correctly and check when we
do not actually need to delete.
The attached patch does fix the problem.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1
2015-10-08 22:44 [Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1 ylow at graphlab dot com
@ 2015-10-09 8:09 ` rguenth at gcc dot gnu.org
2015-10-09 12:02 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-10-09 8:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67903
--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
To me it looks like the issue is that when statically linking libstdc++ into a
shared library you export the symbols of that libstdc++ copy and thus they
participate in merging. So my suggestion is that you use a version script
(for example) to only export symbols from your shared library and not
libstdc++.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1
2015-10-08 22:44 [Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1 ylow at graphlab dot com
2015-10-09 8:09 ` [Bug libstdc++/67903] " rguenth at gcc dot gnu.org
@ 2015-10-09 12:02 ` redi at gcc dot gnu.org
2015-10-09 12:04 ` redi at gcc dot gnu.org
2015-10-09 17:10 ` ylow at graphlab dot com
3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2015-10-09 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67903
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Yucheng Low from comment #0)
> This would not be a problem if not for the fact that:
> - the global locale is initialized with an inplace new:
> locale_init.cc:378
> _M_facets = new (&facet_vec) const facet*[_M_facets_size];
> _M_caches = new (&cache_vec) const facet*[_M_facets_size];
> - the locale inserter (locale_init.cc:354) correctly checks when it
> should
> extend the _M_facets, but happily just deletes the old array.
> locale.cc:348
> delete [] __oldf;
> delete [] __oldc;
> - which of course fails gloriously with the inplace new.
>
> - The solution is to actually do the resize correctly and check when we
> do not actually need to delete.
A better check might be to compare the pointers with the buffers used for the
placement new.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1
2015-10-08 22:44 [Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1 ylow at graphlab dot com
2015-10-09 8:09 ` [Bug libstdc++/67903] " rguenth at gcc dot gnu.org
2015-10-09 12:02 ` redi at gcc dot gnu.org
@ 2015-10-09 12:04 ` redi at gcc dot gnu.org
2015-10-09 17:10 ` ylow at graphlab dot com
3 siblings, 0 replies; 5+ messages in thread
From: redi at gcc dot gnu.org @ 2015-10-09 12:04 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67903
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(If this is something that should be fixed in the library at all),
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1
2015-10-08 22:44 [Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1 ylow at graphlab dot com
` (2 preceding siblings ...)
2015-10-09 12:04 ` redi at gcc dot gnu.org
@ 2015-10-09 17:10 ` ylow at graphlab dot com
3 siblings, 0 replies; 5+ messages in thread
From: ylow at graphlab dot com @ 2015-10-09 17:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67903
--- Comment #4 from Yucheng Low <ylow at graphlab dot com> ---
I have tried version scripts and it ought to work but I couldn't quite figure
out what symbols to hide.
In any case, the proposed modification does fix a questionable bit of code in
locale.cc (i.e. the resize code path in _M_install_facet is problematic due to
the deletion of a placement new).
The effect that it resolves a compatibility issue is a pleasant side effect.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2015-10-09 17:10 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-10-08 22:44 [Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1 ylow at graphlab dot com
2015-10-09 8:09 ` [Bug libstdc++/67903] " rguenth at gcc dot gnu.org
2015-10-09 12:02 ` redi at gcc dot gnu.org
2015-10-09 12:04 ` redi at gcc dot gnu.org
2015-10-09 17:10 ` ylow at graphlab dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).