This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/62100] New: c++11 threads invoke pure virtual function on arm embedded system
- From: "pab at pabigot dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 11 Aug 2014 23:23:47 +0000
- Subject: [Bug libstdc++/62100] New: c++11 threads invoke pure virtual function on arm embedded system
- Auto-submitted: auto-generated
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.