[Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1

[Bug libstdc++/67903] New: std::locale compatibility between gcc4.9 and gcc5.1

[ylow at graphlab dot com]

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.

[Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1

[rguenth at gcc dot gnu.org]

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

[Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1

[redi at gcc dot gnu.org]

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.

[Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1

[redi at gcc dot gnu.org]

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

[Bug libstdc++/67903] std::locale compatibility between gcc4.9 and gcc5.1

[ylow at graphlab dot com]

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.