https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336
Bug ID: 113336
Summary: libatomic (testsuite) regressions on
armv6-linux-gnueabihf
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: roger at nextmovesoftware dot com
Target Milestone: ---
As suggested by Richard Earnshaw, this opens a bugzilla PR for tracking this
issue. All the tests in libatomic currently fail on a raspberry pi running
raspbian, but passed back in December 2020.
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642168.html
The regression (which isn't really a regression) was caused by:
2023-09-26 Hans-Peter Nilsson <[email protected]>
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.
Prior to this, when -fno-sync-libcalls was specified on the command line, the
__atomic_test_and_set built-in simply expanded to a non-atomic code sequence,
which then passed libatomic's configure tests for HAVE_ATOMIC_TAS. Now that
this hole/bug/correctness issue has been fixed, and HAVE_ATOMIC_TAS is now
detected as false, the libatomics's tas_n.c can no longer implement tas_8_2_.o
without (a missing helper function) tas_1_2_.o.
Hence libatomic has (always?) been broken on armv6, but synchronization
primitives can now be supported with the above change. We've just not noticed
that necessary pieces of the runtime were missing, until the above correctness
fix resulted in a link error.
