https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118977
Joel Sherrill <joel at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2025-5-3
Known to fail| |14.0
Known to work| |13.0
--- Comment #4 from Joel Sherrill <joel at gcc dot gnu.org> ---
I managed to narrow down the commit that broke this. RTEMS has some functions
to support libatomic in libatomic/config/rtems. What tiny bit of magic are we
missing for CPUs that don't have the instruction. Help providing
__atomic_test_and_set is appreciated.
commit 8e6757b30d0f3f13d47d0f842801a751ba6293c2 (HEAD)
Author: Hans-Peter Nilsson <h...@axis.com>
Date: Sat Sep 23 05:06:52 2023 +0200
__atomic_test_and_set: Fall back to library, not non-atomic code
Make __atomic_test_and_set consistent with other __atomic_ and __sync_
builtins: call a matching library function instead of emitting
non-atomic code when the target has no direct insn support.
There's special-case code handling targetm.atomic_test_and_set_trueval
!= 1 trying a modified maybe_emit_sync_lock_test_and_set. Previously,
if that worked but its matching emit_store_flag_force returned NULL,
we'd segfault later on. Now that the caller handles NULL, gcc_assert
here instead.
While the referenced PR:s are ARM-specific, the issue is general.
PR target/107567
PR target/109166
* builtins.cc (expand_builtin) <case BUILT_IN_ATOMIC_TEST_AND_SET>:
Handle failure from expand_builtin_atomic_test_and_set.
* optabs.cc (expand_atomic_test_and_set): When all attempts fail to
generate atomic code through target support, return NULL
instead of emitting non-atomic code. Also, for code handling
targetm.atomic_test_and_set_trueval != 1, gcc_assert result
from calling emit_store_flag_force instead of returning NULL.
