https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109166
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Hans-Peter Nilsson <h...@gcc.gnu.org>: https://gcc.gnu.org/g:8e6757b30d0f3f13d47d0f842801a751ba6293c2 commit r14-4286-g8e6757b30d0f3f13d47d0f842801a751ba6293c2 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.
