aboutsummaryrefslogtreecommitdiff
path: root/libjava/classpath/java
diff options
context:
space:
mode:
authorJonathan Wakely <jwakely@redhat.com>2025-12-09 21:02:56 +0000
committerJonathan Wakely <redi@gcc.gnu.org>2026-02-06 09:54:14 +0000
commit4046caad61a0406e42cae0c38a6aa26f5975a197 (patch)
tree7344757e3dcb6040d7b5b5bec09eb386fede7b1b /libjava/classpath/java
parent1b6a9697de7616fb12ce8521472f5817a312c6d5 (diff)
downloadgcc-master.zip
gcc-master.tar.gz
gcc-master.tar.bz2
libstdc++: Prevent std::stacktrace from using atomics on arm-eabi [PR120567]HEADtrunkmaster
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/classpath/java')
0 files changed, 0 insertions, 0 deletions