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).