https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70560
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
A related issue is that we decide on shared_ptr locking policy based on a
dynamic property that can change between translation units according to -march:
static const _Lock_policy __default_lock_policy =
#ifdef __GTHREADS
#if (defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2) \
&& defined(__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4))
_S_atomic;
#else
_S_mutex;
#endif
#else
_S_single;
#endif
This causes ABI changes when inconsistent -march values are used, e.g. when
mixing i386 and i686, or armv5 and armv7 (e.g. PR 42734 and PR 67843).
It would be better to fix the lock policy at configure-time, so it is a
constant for a given build of libstdc++.
If, for example, the library is configured for armv7 then the atomic lock
policy will be used, and if user code is compiled with -march=armv5 it will
still use the same policy, and will use the __atomic_add and __exchange_and_add
library functions from libstdc++.so
If the library is configured for armv5 it will use the mutex policy, and if
user code is compiled with -march=armv7 it will still use the same policy.
We might also want to add an option to override the default, so that the
targets can opt to use the atomics, which will call the __atomic_add and
__exchange_and_add functions in libstdc++.so which will use either functions in
libatomic or the kernel helper routines in libgcc.
