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

["victor.donascimento at arm dot com" <gcc-bugzilla@gcc.gnu.org>]

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

Victor Do Nascimento <victor.donascimento at arm dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |victor.donascimento at arm dot com

--- Comment #3 from Victor Do Nascimento <victor.donascimento at arm dot com> ---
For what it's worth, I just so happened to stumble upon the same issue when
compiling and running Libatomic for the armv8l-unknown-linux-gnueabihf triplet
on a Cortex-A72 machine inside a 32-bit Docker container, so the issue is
clearly is clearly prevalent on a wider range of targets than perhaps alluded
to by the bug report title.

The patch provided does appear to fix all regressions.

Here are my initial thoughts on the issue and the proposed fix.

My only concern at the moment is that if the regression is caused by
HAVE_ATOMIC_TAS now being detected as false, then perhaps a more directed
solution is called for, specific to tas, as opposed to generating _i2 variants
for *all* atomic ops via $(addsuffix _1_2_.lo,$(SIZEOBJS))

If you look at the very end of tas_n.c at the `if !DONE' clause, you'll see
that for `SIZE(libat_test_and_set)', irrespective of the SIZE value,
SIZE(libat_test_and_set) always falls back onto `libat_test_and_set_1',
explaining why tas_1_2_.lo is needed.

This unconditional dependence on the *_1 does not, however, appear the norm. 
One example of this is seen with `SIZE(libat_compare_exchange)'.

With this in mind, I notice that adding `tas_1_2_.lo' to the
`libatomic_la_LIBADD' variable in Makefile.am, i.e.

  libatomic_la_LIBADD += tas_1_2_.lo

is apparently sufficient to fix all regressions on my machine.