On Mon, Jan 12, 2026 at 12:13:35PM +0100, Florian Weimer wrote:
> One way to work around the libtool problem would be to stick the
> as-needed into an existing .so linker script, or create a new one under
> a different name (say libatomic_optional.so) that has AS_NEEDED in it,
> and link with -latomic_optional. Then libtool would not have to be
> taught about --push-state/--pop-state etc.
That seems to work.
So far bootstrapped (c,c++,fortran,lto only) and make install tested
on x86_64-linux, tested on a small program without need to libatomic and
struct S { char a[25]; };
_Atomic struct S s;
int main () { struct S t = s; s = t; }
which does at -O0.
Before this patch I got
for i in `find x86_64-pc-linux-gnu/ -name lib\*.so.\*.\*`; do ldd -u $i 2>&1 | grep -q libatomic.so.1 && echo $i; done
x86_64-pc-linux-gnu/libsanitizer/ubsan/.libs/libubsan.so.1.0.0
x86_64-pc-linux-gnu/libsanitizer/asan/.libs/libasan.so.8.0.0
x86_64-pc-linux-gnu/libsanitizer/hwasan/.libs/libhwasan.so.0.0.0
x86_64-pc-linux-gnu/libsanitizer/lsan/.libs/liblsan.so.0.0.0
x86_64-pc-linux-gnu/libsanitizer/tsan/.libs/libtsan.so.2.0.0
x86_64-pc-linux-gnu/32/libsanitizer/ubsan/.libs/libubsan.so.1.0.0
x86_64-pc-linux-gnu/32/libsanitizer/asan/.libs/libasan.so.8.0.0
x86_64-pc-linux-gnu/32/libstdc++-v3/src/.libs/libstdc++.so.6.0.35
x86_64-pc-linux-gnu/libgcobol/.libs/libgcobol.so.2.0.0
x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.35
With this patch it prints nothing.
2026-01-13 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/123396
gcc/
* configure.ac (gcc_cv_ld_use_as_needed_ldscript): New test.
(USE_LD_AS_NEEDED_LDSCRIPT): New AC_DEFINE.
* gcc.cc (LINK_LIBATOMIC_SPEC): Use "-latomic_asneeded" instead
of LD_AS_NEEDED_OPTION " -latomic " LD_NO_AS_NEEDED_OPTION
if USE_LD_AS_NEEDED_LDSCRIPT is defined.
(init_gcc_specs): Use "-lgcc_s_asneeded" instead of
LD_AS_NEEDED_OPTION " -lgcc_s " LD_NO_AS_NEEDED_OPTION
if USE_LD_AS_NEEDED_LDSCRIPT is defined.
* config.in: Regenerate.
* configure: Regenerate.
libatomic/
* acinclude.m4 (LIBAT_BUILD_ASNEEDED_SOLINK): New AM_CONDITIONAL.
* libatomic_asneeded.so: New file.
* libatomic_asneeded.a: New file.
* Makefile.am (toolexeclib_DATA): Set if LIBAT_BUILD_ASNEEDED_SOLINK.
(all-local): Install those files into gcc subdir.
* Makefile.in: Regenerate.
* configure: Regenerate.
libgcc/
* config/t-slibgcc (SHLIB_ASNEEDED_SOLINK,
SHLIB_MAKE_ASNEEDED_SOLINK, SHLIB_INSTALL_ASNEEDED_SOLINK): New
vars.
(SHLIB_LINK): Include $(SHLIB_MAKE_ASNEEDED_SOLINK).
(SHLIB_INSTALL): Include $(SHLIB_INSTALL_ASNEEDED_SOLINK).
GNU ld gained separate Solaris-specific linker emulations (*_sol2) long
ago. Since their introduction, GCC has preferred them over their
non-*_sol2 counterparts but supported both forms. This has changed for
GCC 16: since all supported versions of GNU ld do support the *_sol2
emulations, GCC now uses them unconditionally.
libtool has also been updated to handle this since libtool 2.4.2 back in
2011. However, that change has only partially been backported to the
heavily patched libtool.m4 in the GCC tree: the sparcv9 part is there,
but the amd64 part is missing for some reason. This causes problems
with some recent binutils changes.
Therefore this patch cherry-picks the libtool patch to bring
Solaris/x86_64 in sync with Solaris/sparcv9 and upstream libtool.
Bootstrapped without regressions on {amd64,i386}-pc-solaris2.11 and
{sparcv9,sparc}-sun-solaris2.11.
2025-09-22 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
* libtool.m4: Cherry-pick libtool commit
9196966580f6853a31187a7a3c7e7ff36ef08982.
gcc:
* configure: Regenerate.
libatomic:
* configure: Regenerate.
libbacktrace:
* configure: Regenerate.
libcc1:
* configure: Regenerate.
libffi:
* configure: Regenerate.
libga68:
* configure: Regenerate.
libgcobol:
* configure: Regenerate.
libgfortran:
* configure: Regenerate.
libgm2:
* configure: Regenerate.
libgomp:
* configure: Regenerate.
libgrust:
* configure: Regenerate.
libitm:
* configure: Regenerate.
libobjc:
* configure: Regenerate.
libphobos:
* configure: Regenerate.
libquadmath:
* configure: Regenerate.
libsanitizer:
* configure: Regenerate.
libssp:
* configure: Regenerate.
libstdc++-v3:
* configure: Regenerate.
libvtv:
* configure: Regenerate.
lto-plugin:
* configure: Regenerate.
zlib:
* configure: Regenerate.
After regeneration in commit e5d853bbe9 ("Factor out thread model
detection with new `GCC_AC_THREAD_MODEL` macro") some whitespace was
removed from the Makefile.in files under libatomic. Fix this by
regenerating them again.
libatomic/ChangeLog:
* Makefile.in: Regenerate.
* testsuite/Makefile.in: Regenerate.
This macro deduplicates the
$CC -v 2>&1 | sed -n 's/^Thread model: //p'
check that was occurring in various runtime libs.
Additionally, as a bit of an Easter egg, this also allows overriding
what the compiler would return by setting the
`gcc_cv_target_thread_file` cache variable first. I admit that it is in
fact this Easter egg that led me to write the patch. The use-case for it
is for making multilib builds where the library sets do not all share
the same thread model easier. See also `THREAD_MODEL_SPEC` for more
about the varying thread models use-case.
Arguably one could could try to define on `THREAD_MODEL_SPEC` on more
platforms (besides e.g. AIX) but the ramifications of this are a bit
unclear. Setting `gcc_cv_target_thread_file` directly is a "low tech"
solution that will work for now for sure. Of course, since setting a
cache variable like this a hacky trick, I will not expect this to be at
all stable/guaranteed to work, going forward.
Thanks to Arsen who on IRC discussed these things with me, including in
particular making it a cache var not `--with-model` flag, to not
prematurely foster expectations that this is stable.
Suggested-by: Arsen Arsenović <arsen@aarsen.me>
config/ChangeLog:
* gthr.m4: Create new GCC_AC_THREAD_MODEL macro
libatomic/ChangeLog:
* Makefile.in: Regenerate.
* aclocal.m4: Regenerate.
* configure: Regenerate.
* configure.ac: Use GCC_AC_THREAD_MODEL instead of hand-rolled
* testsuite/Makefile.in: Regenerate.
libgcc/ChangeLog:
* configure: Regenerate.
* configure.ac: Use GCC_AC_THREAD_MODEL instead of hand-rolled
libphobos/ChangeLog:
* configure: Regenerate.
* m4/druntime/os.m4: Use AC_MSG_ERROR, not private as_fn_error
libstdc++-v3/ChangeLog:
* acinclude.m4: Use GCC_AC_THREAD_MODEL instead, via AC_REQUIRE
* configure: Regenerate.
As [1] says, we cannot mix up lock-free and locking atomics for one
object. For example assume atom = (0, 0) initially, if we have a
locking "atomic" xor running on T0 and a lock-free store running on T1
concurrently:
T0 | T1
-----------------------------+-------------------------------------
acquire_lock |
t0 = atom[0] |
/* some CPU cycles */ | atom = (1, 1) /* lock-free atomic */
t1 = atom[1] |
t0 ^= 1 |
t1 ^= 1 |
atom[0] = t0 |
atom[1] = t1 |
release_lock |
we get atom = (0, 1), but the atomicity of xor and store should
guarantee that atom is either (0, 0) or (1, 1).
So, if we want to use a lock-free 16B atomic operation, we need both LSX
and SCQ even if that specific operation only needs one of them. To make
things worse, one may link a TU compiled with -mlsx -mscq and another
without them together, then if we want to use the lock-free 16B atomic
operations in the former, we must make libatomic also use the lock-free
16B atomic operation for the latter so we need to add ifuncs for
libatomic, similar to the discussion about i386 vs. i486 in [1].
Implementing and building the ifuncs currently requires:
- Glibc, because the ifunc resolver interface is libc-specific
- Linux, because the HWCAP bit for LSX is kernel-specific
- A recent enough assembler at build time to recognize sc.q
So the approach here is: only allow 16B lock-free atomic operations in
the compiler if the criteria above is satisfied, and ensure libatomic to
use those lock-free operations on capable hardware (via ifunc unless
both LSX and SCQ are already enabled by the builder) if the compiler
allows 16B lock-free atomic.
[1]: https://gcc.gnu.org/wiki/Atomic/GCCMM/LIbrary
gcc/
* configure.ac (HAVE_AS_16B_ATOMIC): Define if the assembler
supports LSX and sc.q.
* configure: Regenerate.
* config.in: Regenerate.
* config/loongarch/loongarch-opts.h (HAVE_AS_16B_ATOMIC):
Defined to 0 if undefined yet.
* config/loongarch/linux.h (HAVE_IFUNC_FOR_LIBATOMIC_16B):
Define as HAVE_AS_16B_ATOMIC && OPTION_GLIBC.
* config/loongarch/loongarch-protos.h
(loongarch_16b_atomic_lock_free_p): New prototype.
* config/loongarch/loongarch.cc
(loongarch_16b_atomic_lock_free_p): Implement.
* config/loongarch/sync.md (atomic_storeti_lsx): Require
loongarch_16b_atomic_lock_free_p.
(atomic_storeti): Likewise.
(atomic_exchangeti_scq): Likewise.
(atomic_exchangeti): Likewise.
(atomic_compare_and_swapti): Likewise.
(atomic_fetch_<amop_ti_fetch>ti_scq): Likewise.
(atomic_fetch_<amop_ti_fetch>ti): Likewise.
(ALL_SC): Likewise for TImode.
(atomic_storeti_scq): Remove.
libatomic/
* configure.ac (ARCH_LOONGARCH): New AM_CONDITIONAL.
* Makefile.am (IFUNC_OPT): Separate the item from IFUNC_OPTIONS
to allow using multiple options for an ISA variant.
(libatomic_la_LIBADD): Add *_16_1_.lo for LoongArch.
(IFUNC_OPTIONS): Build *_16_1_.lo for LoongArch with -mlsx and
-mscq.
* configure: Regenerate.
* Makefile.in: Regenerate.
* configure.tgt (try_ifunc): Set to yes for LoongArch if the
compiler can produce lock-free 16B atomic with -mlsx -mscq.
* config/loongarch/host-config.h: Implement ifunc selector.
This optional header is used to bring in the definition of the
struct __ifunc_arg_t type. Since it has been added to glibc only
recently, the previous implementation had to check whether this
header is present and, if not, it provide its own definition.
This creates dead code because either one of these two parts would
not be tested. The ABI specification for ifunc resolvers allows to
create own ABI-compatible definition for this type, which is the
right way of doing it.
In addition to improving consistency, the new approach also helps
with addition of new fields to struct __ifunc_arg_t type without
the need to work-around situations when the definition imported
from the header lacks these new fields.
ABI allows to define as many hwcap fields in this struct as needed,
provided that at runtime we only access the fields that are permitted
by the _size value.
gcc/
* config/aarch64/aarch64.cc (build_ifunc_arg_type):
Add new fields _hwcap3 and _hwcap4.
libatomic/
* config/linux/aarch64/host-config.h (__ifunc_arg_t):
Remove sys/ifunc.h and add new fields _hwcap3 and _hwcap4.
libgcc/
* config/aarch64/cpuinfo.c (__ifunc_arg_t): Likewise.
(__init_cpu_features): obtain and assign values for the
fields _hwcap3 and _hwcap4.
(__init_cpu_features_constructor): check _size in the
arg argument.
Since vxworks' libc contains much of libatomic, in not-very-granular
modules, building all of libatomic doesn't work very well.
However, some expected entry points are not present in libc, so
arrange for libatomic to build only those missing bits.
for libatomic/ChangeLog
* configure.tgt: Set partial_libatomic on *-*-vxworks*.
* configure.ac (PARTIAL_VXWORKS): New AM_CONDITIONAL.
* Makefile.am (libatomic_la_SOURCES): Select few sources for
PARTIAL_VXWORKS.
* configure, Makefile.in: Rebuilt.
In r15-3752-g48261bd26df624 I added a test plugin that overrode the
regular output, instead emitting diagnostics in crude HTML form.
In r15-4760-g0b73e9382ab51c I added support for multiple kinds of
diagnostic output simultaneously, adding
-fdiagnostics-add-output=DIAGNOSTICS-OUTPUT-SPEC
-fdiagnostics-set-output=DIAGNOSTICS-OUTPUT-SPEC
for adding/changing the kind of diagnostics output, supporting
"text" and "sarif" output schemes.
This patch promotes the HTML output code from the test plugins so
that it is available from "-fdiagnostics-add-output=", using a
new "experimental-html" scheme, to allow simultaneous text, sarif
and html output, and to make it easier to experiment with. The
patch adds Python-based testing of the emitted HTML.
The patch does not affect the generated HTML, which is still crude, and
not yet ready for end-users. I hope to improve it in followups.
gcc/ChangeLog:
PR other/116792
* Makefile.in (OBJS-libcommon): Add diagnostic-format-html.o.
* diagnostic-format-html.cc: Move here from
testsuite/gcc.dg/plugin/diagnostic_plugin_xhtml_format.cc.
Simplify includes. Rename "xhtml" to "html" throughout.
(write_escaped_text): Drop.
(class xhtml_stream_output_format): Drop.
(class html_file_output_format): Reimplement using
diagnostic_output_file.
(diagnostic_output_format_init_xhtml): Drop.
(diagnostic_output_format_init_xhtml_stderr): Drop.
(diagnostic_output_format_init_xhtml_file): Drop.
(diagnostic_output_format_open_html_file): New.
(make_html_sink): New.
(xhtml_format_selftests): Convert to...
(diagnostic_format_html_cc_tests): ...this.
(plugin_is_GPL_compatible): Drop.
(plugin_init): Drop.
* diagnostic-format-html.h: New file.
* doc/invoke.texi (-fdiagnostics-add-output=): Add
"experimental-html" scheme.
* opts-diagnostic.cc: Include "diagnostic-format-html.h".
(class html_scheme_handler): New.
(output_factory::output_factory): Add html_scheme_handler.
(html_scheme_handler::make_sink): New.
* selftest-run-tests.cc (selftest::run_tests): Call the new
selftests.
* selftest.h (selftest::diagnostic_format_html_cc_tests): New
decl.
gcc/testsuite/ChangeLog:
PR other/116792
* gcc.dg/plugin/diagnostic_plugin_xhtml_format.cc: Move to
gcc/diagnostic-format-html.cc.
* gcc.dg/html-output/html-output.exp: New support script.
* gcc.dg/html-output/missing-semicolon.c: New test.
* gcc.dg/html-output/missing-semicolon.py: New test script.
* gcc.dg/plugin/diagnostic-test-xhtml-1.c: Deleted test.
* gcc.dg/plugin/plugin.exp (plugin_test_list): Drop moved plugin
and its deleted test.
* lib/gcc-dg.exp (load_lib): Add load_lib of scanhtml.exp.
* lib/htmltest.py: New support script.
* lib/scanhtml.exp: New support script, based on scansarif.exp.
libatomic/ChangeLog:
PR other/116792
* testsuite/lib/libatomic.exp: Add load_lib of scanhtml.exp.
libgomp/ChangeLog:
PR other/116792
* testsuite/lib/libgomp.exp: Add load_lib of scanhtml.exp.
libitm/ChangeLog:
PR other/116792
* testsuite/lib/libitm.exp: Add load_lib of scanhtml.exp.
libphobos/ChangeLog:
PR other/116792
* testsuite/lib/libphobos-dg.exp: Add load_lib of scanhtml.exp.
libvtv/ChangeLog:
PR other/116792
* testsuite/lib/libvtv-dg.exp: Add load_lib of scanhtml.exp.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Here is just a port of the previously posted patch to mingw which
clearly has the same problems.
2025-04-16 Jakub Jelinek <jakub@redhat.com>
PR libgcc/101075
PR libgcc/119796
* config/mingw/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE). If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.
As mentioned in the PR (and I think in PR101075 too), we can run into
deadlock with libat_lock_n calls with larger n.
As mentioned in PR66842, we use multiple locks (normally 64 mutexes
for each 64 byte cache line in 4KiB page) and currently can lock more
than one lock, in particular for n [0, 64] a single lock, for n [65, 128]
2 locks, for n [129, 192] 3 locks etc.
There are two problems with this:
1) we can deadlock if there is some wrap-around, because the locks are
acquired always in the order from addr_hash (ptr) up to
locks[NLOCKS-1].mutex and then if needed from locks[0].mutex onwards;
so if e.g. 2 threads perform libat_lock_n with n = 2048+64, in one
case at pointer starting at page boundary and in another case at
page boundary + 2048 bytes, the first thread can lock the first
32 mutexes, the second thread can lock the last 32 mutexes and
then first thread wait for the lock 32 held by second thread and
second thread wait for the lock 0 held by the first thread;
fixed below by always locking the locks in order of increasing
index, if there is a wrap-around, by locking in 2 loops, first
locking some locks at the start of the array and second at the
end of it
2) the number of locks seems to be determined solely depending on the
n value, I think that is wrong, we don't know the structure alignment
on the libatomic side, it could very well be 1 byte aligned struct,
and so how many cachelines are actually (partly or fully) occupied
by the atomic access depends not just on the size, but also on
ptr % WATCH_SIZE, e.g. 2 byte structure at address page_boundary+63
should IMHO lock 2 locks because it occupies the first and second
cacheline
Note, before this patch it locked exactly one lock for n = 0, while
with this patch it could lock either no locks at all (if it is at cacheline
boundary) or 1 (otherwise).
Dunno of libatomic APIs can be called for zero sizes and whether
we actually care that much how many mutexes are locked in that case,
because one can't actually read/write anything into zero sized memory.
If you think it is important, I could add else if (nlocks == 0) nlocks = 1;
in both spots.
2025-04-16 Jakub Jelinek <jakub@redhat.com>
PR libgcc/101075
PR libgcc/119796
* config/posix/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE). If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.
Simplify and cleanup ifunc selection logic. Since LRCPC3 does
not imply LSE2, has_rcpc3() should also check LSE2 is enabled.
Passes regress and bootstrap, OK for commit?
libatomic:
* config/linux/aarch64/host-config.h (has_lse2): Cleanup.
(has_lse128): Likewise.
(has_rcpc3): Add early check for LSE2.
I need to use this cleanup logic for the testsuite for libdiagnostics
where it's too awkward to directly use gcc-dg.exp itself.
No functional change intended.
gcc/testsuite/ChangeLog:
* lib/dg-test-cleanup.exp: New file, from material moved from
lib/gcc-dg.exp.
* lib/gcc-dg.exp: Add load_lib of dg-test-cleanup.exp.
(cleanup-after-saved-dg-test): Move to lib/dg-test-cleanup.exp.
(dg-test): Likewise for override.
(initialize_prune_notes): Likewise.
libatomic/ChangeLog:
* testsuite/lib/libatomic.exp: Add
"load_gcc_lib dg-test-cleanup.exp".
libgomp/ChangeLog:
* testsuite/lib/libgomp.exp: Add
"load_gcc_lib dg-test-cleanup.exp".
libitm/ChangeLog:
* testsuite/lib/libitm.exp: Add
"load_gcc_lib dg-test-cleanup.exp".
libphobos/ChangeLog:
* testsuite/lib/libphobos-dg.exp: Add
"load_gcc_lib dg-test-cleanup.exp".
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp: Add
"load_gcc_lib dg-test-cleanup.exp".
libvtv/ChangeLog:
* testsuite/lib/libvtv.exp: Add
"load_gcc_lib dg-test-cleanup.exp".
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Since r15-3254-g3f51f0dc88ec21c1ec79df694200f10ef85915f4
added scan-ltrans-rtl* variants to scanltranstree.exp, it no longer
makes sense to have "tree" in the name. This renames the file
accordingly and updates users.
libatomic/ChangeLog:
* testsuite/lib/libatomic.exp: Load scanltrans.exp instead of
scanltranstree.exp.
libgomp/ChangeLog:
* testsuite/lib/libgomp.exp: Load scanltrans.exp instead of
scanltranstree.exp.
libitm/ChangeLog:
* testsuite/lib/libitm.exp: Load scanltrans.exp instead of
scanltranstree.exp.
libphobos/ChangeLog:
* testsuite/lib/libphobos-dg.exp: Load scanltrans.exp instead of
scanltranstree.exp.
libvtv/ChangeLog:
* testsuite/lib/libvtv.exp: Load scanltrans.exp instead of
scanltranstree.exp.
gcc/testsuite/ChangeLog:
* gcc.dg-selftests/dg-final.exp: Load scanltrans.exp instead of
scanltranstree.exp.
* lib/gcc-dg.exp: Likewise.
* lib/scanltranstree.exp: Rename to ...
* lib/scanltrans.exp: ... this.
Check the result of __get_cpuid and process FEAT1_REGISTER only when
__get_cpuid returns success. Use __cpuid instead of nested __get_cpuid.
libatomic/ChangeLog:
* config/x86/init.c (__libat_feat1_init): Check the result of
__get_cpuid and process FEAT1_REGISTER only when __get_cpuid
returns success. Use __cpuid instead of nested __get_cpuid.
The introduction of the optional RCPC3 architectural extension for
Armv8.2-A upwards provides additional support for the release
consistency model, introducing the Load-Acquire RCpc Pair Ordered, and
Store-Release Pair Ordered operations in the form of LDIAPP and STILP.
These operations are single-copy atomic on cores which also implement
LSE2 and, as such, support for these operations is added to Libatomic
and employed accordingly when the LSE2 and RCPC3 features are detected
in a given core at runtime.
libatomic/ChangeLog:
* config/linux/aarch64/atomic_16.S (libat_load_16): Add LRCPC3
variant.
(libat_store_16): Likewise.
* config/linux/aarch64/host-config.h (HWCAP2_LRCPC3): New.
(LSE2_LRCPC3_ATOP): Previously LSE2_ATOP. New ifuncs guarded
under it.
(has_rcpc3): New.
At present, `atomic_16.S' groups different implementations of the
same functions together in the file. Therefore, as an example,
the LSE2 implementation of `load_16' follows on immediately from its
core implementation, as does the `store_16' LSE2 implementation.
Such architectural extension-dependent implementations are dependent
on ifunc support, such that they are guarded by the relevant
preprocessor macro, i.e. `#if HAVE_IFUNC'.
Having to apply these guards on a per-function basis adds unnecessary
clutter to the file and makes its maintenance more error-prone.
We therefore reorganize the layout of the file in such a way that all
core implementations needing no `#ifdef's are placed first, followed
by all ifunc-dependent implementations, which can all be guarded by a
single `#if HAVE_IFUNC', greatly reducing the overall number of
required `#ifdef' macros.
libatomic/ChangeLog:
* config/linux/aarch64/atomic_16.S: Reorganize functions in
file.
(HAVE_FEAT_LSE2): Delete.
By querying previously-defined file-identifier macros, `host-config.h'
is able to get information about its environment and, based on this
information, select more appropriate function-specific ifunc
selectors. This reduces the number of unnecessary feature tests that
need to be carried out in order to find the best atomic implementation
for a function at run-time.
An immediate benefit of this is that we can further fine-tune the
architectural requirements for each atomic function without risk of
incurring the maintenance and runtime-performance penalties of having
to maintain an ifunc selector with a huge number of alternatives, most
of which are irrelevant for any particular function. Consequently,
for AArch64 targets, we relax the architectural requirements of
`compare_exchange_16', which now requires only LSE as opposed to the
newer LSE2.
The new flexibility provided by this approach also means that certain
functions can now be called directly, doing away with ifunc selectors
altogether when only a single implementation is available for it on a
given target. As per the macro expansion framework laid out in
`libatomic_i.h', such functions should have their names prefixed with
`__atomic_' as opposed to `libat_'. This is the same prefix applied
to function names when Libatomic is configured with
`--disable-gnu-indirect-function'.
To achieve this, these functions unconditionally apply the aliasing
rule that at present is conditionally applied only when libatomic is
built without ifunc support, which ensures that the default
`libat_##NAME' is accessible via the equivalent `__atomic_##NAME' too.
This is ensured by using the new `ENTRY_ALIASED' macro.
Finally, this means we are able to do away with a whole set of
function aliases that were needed until now, thus considerably
cleaning up the implementation.
libatomic/ChangeLog:
* config/linux/aarch64/atomic_16.S: Remove unnecessary
aliasing.
(LSE): New.
(ENTRY_ALIASED): Likewise.
* config/linux/aarch64/host-config.h (LSE_ATOP): New.
(LSE2_ATOP): Likewise.
(LSE128_ATOP): Likewise.
(IFUNC_COND_1): Make its definition conditional on above 3
macros.
(IFUNC_NCOND): Likewise.
