[Bug target/107567] __atomic_test_and_set generates non-atomic code on armv6-m

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107567

--- Comment #1 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Hans-Peter Nilsson <hp@gcc.gnu.org>:

https://gcc.gnu.org/g:8e6757b30d0f3f13d47d0f842801a751ba6293c2

commit r14-4286-g8e6757b30d0f3f13d47d0f842801a751ba6293c2
Author: Hans-Peter Nilsson <hp@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.