[Bug other/113336] New: libatomic (testsuite) regressions on armv6-linux-gnueabihf

["roger at nextmovesoftware dot com" <gcc-bugzilla@gcc.gnu.org>]

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  <hp@axis.com>

        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.