diff options
author | Jakub Jelinek <jakub@redhat.com> | 2024-11-27 14:33:16 +0100 |
---|---|---|
committer | Jakub Jelinek <jakub@gcc.gnu.org> | 2024-11-27 14:33:16 +0100 |
commit | 96ccb208e43a7cb7a1b15e28c94d57661bf9caae (patch) | |
tree | ca769aff0bcd3dbfd28d20b74a2aa9056b3b6ce1 /gcc/c/c-parser.cc | |
parent | a2370cc4f47fa7f1b2c72135ee1685551c2e25f4 (diff) | |
download | gcc-96ccb208e43a7cb7a1b15e28c94d57661bf9caae.zip gcc-96ccb208e43a7cb7a1b15e28c94d57661bf9caae.tar.gz gcc-96ccb208e43a7cb7a1b15e28c94d57661bf9caae.tar.bz2 |
builtins: Emit __sync_lock_release_{8,16} call as last resort instead of doing nothing [PR117642]
As the following testcases show, in case of multi-word
__sync_lock_test_and_set where we don't actually support atomics for that
size (__int128 for x86_64 lp64 with -mno-cx16, long long for ia32 with
-march=i{3,4}86), as the last fallback if we don't know anything else
we just emit calls to __sync_lock_test_and_set_{8,16}. Those aren't defined
in libatomic, but perhaps users could define them themselves.
While __sync_lock_release if it gives up and has no way to emit the atomic
store just does nothing at all, so no clear sign to the users something
went wrong and that the code will not do what they expected.
This regressed when __atomic_* support has been introduced, previously we
would just emit those calls even in this case.
The patch just emits the call as the last fallback.
2024-11-27 Jakub Jelinek <jakub@redhat.com>
PR target/117642
* builtins.cc (expand_builtin_sync_lock_release): Change return type
from void to rtx, return result of expand_atomic_store.
(expand_builtin) <case BUILT_IN_SYNC_LOCK_RELEASE_16>: If
expand_builtin_sync_lock_release returns NULL, do a break rather
than return const0_rtx.
* gcc.target/i386/pr117642-1.c: New test.
* gcc.target/i386/pr117642-2.c: New test.
Diffstat (limited to 'gcc/c/c-parser.cc')
0 files changed, 0 insertions, 0 deletions