The conftest.cc in GLIBCXX_ENABLE_BACKTRACE checks if calls to
__atomic_load and __atomic_store result in libatomic calls. For arm-eabi
those expand to normal loads with a call to __sync_synchronize to ensure
correct ordering. That means the generated assembly does not match the
grep pattern "__atomic_" and so configure incorrectly assumes we can use
atomics in libbacktrace.
The fix is to grep for "__atomic_|__sync_" instead of just "__atomic_".
As explained in the bug comments, the similar grep for "__atomic_" in
the GLIBCXX_ENABLE_ATOMIC_BUILTINS macro doesn't need the same change.
That conftest.cc program does emit a call to a libatomic function that
matches the grep pattern "__atomic_" so the test gives the right answer
for arm-eabi.
libstdc++-v3/ChangeLog:
PR libstdc++/120567
* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Include "__sync_" in
grep command to check for extern calls to libatomic.
* configure: Regenerate.
Reviewed-by: Tomasz KamiĆski <tkaminsk@redhat.com>
AC_MSG_CHECKING([for atomic builtins for libbacktrace])
if AC_TRY_EVAL(ac_compile); then
- if grep __atomic_ conftest.s >/dev/null 2>&1 ; then
+ if grep -E '__atomic_|__sync_' conftest.s >/dev/null 2>&1 ; then
glibcxx_cv_libbacktrace_atomics=no
else
glibcxx_cv_libbacktrace_atomics=yes
ac_status=$?
$as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
test $ac_status = 0; }; then
- if grep __atomic_ conftest.s >/dev/null 2>&1 ; then
+ if grep -E '__atomic_|__sync_' conftest.s >/dev/null 2>&1 ; then
glibcxx_cv_libbacktrace_atomics=no
else
glibcxx_cv_libbacktrace_atomics=yes