diff options
| author | Jonathan Wakely <jwakely@redhat.com> | 2025-12-09 21:02:56 +0000 |
|---|---|---|
| committer | Jonathan Wakely <redi@gcc.gnu.org> | 2026-02-06 09:54:14 +0000 |
| commit | 4046caad61a0406e42cae0c38a6aa26f5975a197 (patch) | |
| tree | 7344757e3dcb6040d7b5b5bec09eb386fede7b1b /libjava/gnu/java/lang/management/natVMThreadMXBeanImpl.cc | |
| parent | 1b6a9697de7616fb12ce8521472f5817a312c6d5 (diff) | |
| download | gcc-trunk.zip gcc-trunk.tar.gz gcc-trunk.tar.bz2 | |
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>
Diffstat (limited to 'libjava/gnu/java/lang/management/natVMThreadMXBeanImpl.cc')
0 files changed, 0 insertions, 0 deletions
