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

["ylow at graphlab dot com" <gcc-bugzilla@gcc.gnu.org>]

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.