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

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

[pab at pabigot dot com]

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.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-08-12
     Ever confirmed|0                           |1

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Those macros are only meant to be defined by the compiler, never by users.

If defining them fixes the problem it implies you are not compiling with the
same ABI as your libstdc++ was built with. I can't guess more than that because
you haven't provided any information on your target or how it was configured.

https://gcc.gnu.org/bugs/

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

[pab at pabigot dot com]

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

--- Comment #2 from Peter A. Bigot <pab at pabigot dot com> ---
Thanks.  The compiler and libstdc++ are built using Yocto's standard recipe for
the beaglebone.  Obviously there's something wrong with it; what that would be
is not obvious and probably isn't a gcc problem.  I'll be back when I know
more.

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

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It might be obvious in the output of 'gcc -v'.

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

[pab at pabigot dot com]

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

--- Comment #4 from Peter A. Bigot <pab at pabigot dot com> ---
It's not obvious to me:

beaglebone[98]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/gcc/arm-poky-linux-gnueabi/4.9.1/lto-wrapper
Target: arm-poky-linux-gnueabi
Configured with:
/prj/oe/omap/build-beaglebone-master/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/configure
--build=x86_64-linux --host=arm-poky-linux-gnueabi
--target=arm-poky-linux-gnueabi --prefix=/usr --exec_prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --libexecdir=/usr/lib/gcc
--datadir=/usr/share --sysconfdir=/etc --sharedstatedir=/com
--localstatedir=/var --libdir=/usr/lib --includedir=/usr/include
--oldincludedir=/usr/include --infodir=/usr/share/info --mandir=/usr/share/man
--disable-silent-rules --disable-dependency-tracking
--with-libtool-sysroot=/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone
--with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix
--enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu
--enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi-
--without-local-prefix --enable-target-optspace --enable-lto --enable-libssp
--disable-bootstrap --disable-libmudflap --with-system-zlib
--with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--with-float=hard --with-sysroot=/
--with-build-sysroot=/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone
--with-native-system-header-dir=/prj/oe/omap/build-beaglebone-master/tmp/sysroots/beaglebone/usr/include
--with-gxx-include-dir=/usr/include/c++/4.9.1 --enable-nls
Thread model: posix
gcc version 4.9.1 (GCC) 

Yocto builds libssp libstdc++-v3 libgomp libatomic separately from gcc for
packaging/cross-compile/other reasons that aren't entirely clear to me, so I
suspect the issue arises there.

But one difference is that I'm using -std=c++1y (and sometimes -std=c++11). 
Would that be enough to be an ABI change?  I haven't encountered issues on
x86-64.

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED
     Ever confirmed|1                           |0

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Peter A. Bigot from comment #4)
> But one difference is that I'm using -std=c++1y (and sometimes -std=c++11). 
> Would that be enough to be an ABI change?

No, it shouldn't be (if it is then it's a bug that needs to be fixed).

I agree nothing looks suspicious in that output. If the separately-built
libstdc++ uses different configuration that would be a problem, but it's not
possible to tell from that output.

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

[pab at pabigot dot com]

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

--- Comment #7 from Peter A. Bigot <pab at pabigot dot com> ---
DEAR PEOPLE FROM THE FUTURE:

The problem is that OpenEmbedded used target-specific flags to build the
libraries, but did not ensure that the compiler was configured to default to
the corresponding architecture.  Thus the compiler was defaulting to armv5t
while the libraries were built for armv7-a.

Until fixed in OpenEmbedded upstream a cleaner workaround is to add
-mcpu=cortex-a8 which comes closer to matching the assumptions of the
libraries.

See
http://www.mail-archive.com/openembedded-core@lists.openembedded.org/msg55490.html