[Bug libstdc++/62100] New: c++11 threads invoke pure virtual function on arm embedded system

["pab at pabigot dot com" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100

            Bug ID: 62100
           Summary: c++11 threads invoke pure virtual function on arm
                    embedded system
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: pab at pabigot dot com

Created attachment 33297
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33297&action=edit
reproducing code

The attached program built on the target with the MACHINE=beaglebone gcc-4.9.1
compiler from Yocto/OpenEmbedded poky master produces this error:

beaglebone[16]$ g++ -std=c++1y -pthread test.cc && ./a.out
starting
joining
pure virtual method called
terminate called without an active exception
Aborted (core dumped)

Based on google and discovery of these references:

* https://groups.google.com/d/msg/automatak-dnp3/Jisp_zGhd5I/ck_Cj6nO8joJ

*
http://stackoverflow.com/questions/23583317/c-11-threads-error-pure-virtual-function-called

I've tracked this down to ext/concurrence.h requiring the presence of
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 to
use _S_atomic as the default lock policy instead of _S_mutex.  Defining those
macros allows the program to run correctly:

beaglebone[17]$ g++ -DWITH_HACKERY -std=c++11 -pthread test.cc && ./a.out
starting
joining
doit
done

I believe this is related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52839
and that a better fix is to modify ext/concurrence.h to also use _S_atomic if
_GLIBCXX_ATOMIC_BUILTINS is defined even when the compare-and-swap are not. 
Preliminary testing suggests that this solves the problem.

The discussion at 52839 suggests there's an ABI compatibility issue here; I
don't really understand that (nor, honestly, care, since in this situation the
compiler's going onto an embedded system where I'm not worried about old
binaries).  However, if there's a reason why I shouldn't propose this as a
patch to OpenEmbedded please let me know.