https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120567
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Hans-Peter Nilsson from comment #5) > There's an identical test earlier in those files that also wants change. The other test is only checking for atomics on _Atomic_word, which is usually int. It also tests __atomic_fetch_add rather than __atomic_load and __atomic_store. In theory, that probably should be changed the same way, although changing the outcome of *that* test would be an ABI break. That one is used widely in the library. Either that one is already correct, or it's probably not a good idea to change it now. It happens to be correct already for arm-eabi: configure:16480: checking for atomic builtins for _Atomic_word configure:16482: /home/jwakely/src/gcc/build-arm/gcc-obj/./gcc/xgcc -shared-libgcc -B/home/jwakely/src/gcc/build-arm/gcc-obj/./gcc -nostdinc++ -L/home/jwakely/src/gcc/build-arm/gcc-obj/arm-eabi/libstdc++-v3/src -L/home/jwakely/src/gcc/build-arm/gcc-obj/arm-eabi/libstdc++-v3/src/.libs -L/home/jwakely/src/gcc/build-arm/gcc-obj/arm-eabi/libstdc++-v3/libsupc++/.libs -nostdinc -B/home/jwakely/src/gcc/build-arm/gcc-obj/arm-eabi/newlib/ -isystem /home/jwakely/src/gcc/build-arm/gcc-obj/arm-eabi/newlib/targ-include -isystem /home/jwakely/src/gcc/gcc/newlib/libc/include -B/home/jwakely/src/gcc/build-arm/gcc-obj/arm-eabi/libgloss/arm -L/home/jwakely/src/gcc/build-arm/gcc-obj/arm-eabi/libgloss/libnosys -L/home/jwakely/src/gcc/gcc/libgloss/arm -B/home/jwakely/gcc/arm-eabi/arm-eabi/bin/ -B/home/jwakely/gcc/arm-eabi/arm-eabi/lib/ -isystem /home/jwakely/gcc/arm-eabi/arm-eabi/include -isystem /home/jwakely/gcc/arm-eabi/arm-eabi/sys-include -c -O0 -S conftest.cpp >&5 configure:16485: $? = 0 configure:16493: result: no configure:16519: WARNING: No native atomic operations are provided for this platform. configure:16522: WARNING: They cannot be faked when thread support is disabled. configure:16524: WARNING: Thread-safety of certain classes is not guaranteed. configure:16550: checking for lock policy for shared_ptr reference counts I think the __atomic_fetch_add call is emitted as a libatomic library call, there's no __sync_synchronize call used there. The one that my patch in comment 4 changes is in new-ish code for an experimental C++23 feature and checks for atomic loads and stores on void*, int, and size_t. That's what gives the wrong answer for arm-eabi, and it's not too late to change it now. For those loads and stores, there are no calls to any __atomic_xxx library calls, but there is a __sync_synchronize call. Revisiting the older check for _Atomic_word might make sense, but I'm not aware of targets where it gives the wrong answer, and changing it would need involvement from relevant target maintainers. I feel confident changing the result for std::stacktrace myself, this bug seems fairly clear in scope.
