C23 makes various standard library functions, that return a pointer
into an input array, into macros that return a pointer to const when
the relevant argument passed to the macro is a pointer to const.  (The
requirement is for macros, with the existing function types applying
when macro expansion is suppressed.  When a null pointer constant is
passed, such as integer 0, that's the same as a pointer to non-const.)

Implement this feature.  This only applies to C, not C++, since such
macros are not an appropriate way of doing this for C++ and all the
affected functions other than bsearch have overloads to implement an
equivalent feature for C++ anyway.  Nothing is done to apply such a
change to any non-C23 functions with the same property of returning a
pointer into an input array.

The feature is also disabled when _LIBC is defined, since there are
various places in glibc that either redefine these identifiers as
macros, or define the functions themselves, and would need changing to
work in the presence of these macro definitions.  A natural question
is whether we should in fact change those places and not disable the
macro definitions for _LIBC.  If so, we'd need a solution for the
places in glibc that define the macro *before* including the relevant
header (in order in effect to disable the header declaration of the
function by renaming that declaration).

One testcase has #undef added to avoid conflicting with this feature
and another has const added; -Wno-discarded-qualifiers is added for
building zic (but could be removed once there's a new upstream tzcode
release that's const-safe with this C23 change and glibc has updated
to code from that new release).  Probably other places in glibc proper
would need const added if we remove the _LIBC conditionals.

Another question would be whether some GCC extension should be added
to support this feature better with macros that only expand each
argument once (as well as reducing duplication of diagnostics for bad
usages such as non-pointer and pointer-to-volatile-qualfied
arguments).

Tested for x86_64.

Signed-off-by: Justin King <jcking@google.com>
Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

The support for lock elision was already deprecated with glibc 2.42:
commit 77438db8cfa6ee66b3906230156bdae11c49a195
"Mark support for lock elision as deprecated."
See also discussions:
https://sourceware.org/pipermail/libc-alpha/2025-July/168492.html

This patch removes the architecture specific support for lock elision
for x86, powerpc and s390 by removing the elision-conf.h, elision-conf.c,
elision-lock.c, elision-timed.c, elision-unlock.c, elide.h, htm.h/hle.h files.
Those generic files are also removed.

The architecture specific structures are adjusted and the elision fields are
marked as unused.  See struct_mutex.h files.
Furthermore in struct_rwlock.h, the leftover __rwelision was also removed.
Those were originally removed with commit 0377a7fde6dfcc078dda29a1225d7720a0931357
"nptl: Remove rwlock elision definitions"
and by chance reintroduced with commit 7df8af43ad1cd8ce527444de50bee6f35eebe071
"nptl: Add struct_rwlock.h"

The common code (e.g. the pthread_mutex-files) are changed back to the time
before lock elision was introduced with the x86-support:
- commit 1cdbe579482c07e9f4bb3baa4864da2d3e7eb837
"Add the low level infrastructure for pthreads lock elision with TSX"
- commit b023e4ca99f5e81f90d87d23cd267ef2abd2388c
"Add new internal mutex type flags for elision."
- commit 68cc29355f3334c7ad18f648ff9a6383a0916d23
"Add minimal test suite changes for elision enabled kernels"
- commit e8c659d74e011346785355eeef03b7fb6f533c61
"Add elision to pthread_mutex_{try,timed,un}lock"
- commit 49186d21ef2d87986bccaf0a7c45c48c91b265f3
"Disable elision for any pthread_mutexattr_settype call"
- commit 1717da59aed9612becd56aaa1249aac695af4c8a
"Add a configure option to enable lock elision and disable by default"

Elision is removed also from the tunables, the initialization part, the
pretty-printers and the manual.

Some extra handling in the testsuite is removed as well as the full tst-mutex10
testcase, which tested a race while enabling lock elision.

I've also searched the code for "elision", "elide", "transaction" and e.g.
cleaned some comments.

I've run the testsuite on x86_64 and s390x and run the build-many-glibcs.py
script.
Thanks to Sachin Monga, this patch is also tested on powerpc.

A NEWS entry also mentions the removal.
Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>

As discussed in bug 28327, C23 changed the fromfp functions to return
floating types instead of intmax_t / uintmax_t.  (Although the
motivation in N2548 was reducing the use of intmax_t in library
interfaces, the new version does have the advantage of being able to
specify arbitrary integer widths for e.g. assigning the result to a
_BitInt, as well as being able to indicate an error case in-band with
a NaN return.)

As with other such changes from interfaces introduced in TS 18661,
implement the new types as a replacement for the old ones, with the
old functions remaining as compat symbols but not supported as an API.
The test generator used for many of the tests is updated to handle
both versions of the functions.

Tested for x86_64 and x86, and with build-many-glibcs.py.

Also tested tgmath tests for x86_64 with GCC 7 to make sure that the
modified case for older compilers in <tgmath.h> does work.

Also tested for powerpc64le to cover the ldbl-128ibm implementation
and the other things that are handled differently for that
configuration.  The new tests fail for ibm128, but all the failures
relate to incorrect signs of zero results and turn out to arise from
bugs in the underlying roundl, ceill, truncl and floorl
implementations that I've reported in bug 33623, rather than
indicating any bug in the actual new implementation of the functions
for that format.  So given fixes for those functions (which shouldn't
be hard, and of course should add to the tests for those functions
rather than relying only on indirect testing via fromfp), the fromfp
tests should start passing for ibm128 as well.

It has been added on Linux 6.10 (8be7258aad44b5e25977a98db136f677fa6f4370)
as a way to block operations such as mapping, moving to another location,
shrinking the size, expanding the size, or modifying it to a pre-existing
memory mapping.

Although the system only works on 64-bit CPUs, the entrypoint was added
for all ABIs (since the kernel might eventually implement it for additional
ones and/or the ABI can execute on a 64-bit kernel).

Checked on x86_64-linux-gnu and aarch64-linux-gnu.

Reviewed-by: Collin Funk <collin.funk1@gmail.com>

C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t
(originally introduced in TS 18661-3), analogous to float_t and
double_t.  Add these typedefs to glibc.  (There are no _FloatNx_t
typedefs.)

C23 also slightly changes the rules for how such typedef names should
be defined, compared to the definition in TS 18661-3.  In both cases,
<TYPE>_t corresponds to the evaluation format for <TYPE>, as specified
by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal
__GLIBC_FLT_EVAL_METHOD).  Specifically, each FLT_EVAL_METHOD value
corresponds to some type U (for example, 64 corresponds to U =
_Float64), and for types with exactly the same set of values as U, TS
18661-3 says expressions with those types are to be evaluated to the
range and precision of type U (so <TYPE>_t is defined to U), whereas
C23 only does that for types whose values are a strict subset of those
of type U (so <TYPE>_t is defined to <TYPE>).

As with other cases where semantics changed between TS 18661 and C23,
this patch only implements the newer version of the semantics
(including adjusting existing definitions of float_t and double_t as
needed).  The new semantics are contradictory between the main
standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the
choice of double_t when double and long double have the same values
(the main standard says it's defined as long double in that case,
whereas Annex H would define it as double), which I've raised on the
WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double
and long double have the same values is a fairly theoretical
combination of features); for now glibc follows the value in the main
standard in that case.

Note that I think all existing GCC targets supported by glibc only use
values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header
code is somewhat theoretical, though potentially relevant with other
compilers since the choice of FLT_EVAL_METHOD is only an API choice,
not an ABI one; it can vary with compiler options, and these typedefs
should not be used in ABIs).  The testcase (expanded to cover the new
typedefs) is really just repeating the same logic in a second place
(so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent
with FLT_EVAL_METHOD).

Tested for x86_64 and x86, and with build-many-glibcs.py.

C23 makes assert into a variadic macro to handle cases of an argument
that would be interpreted as a single function argument but more than
one macro argument (in particular, compound literals with an
unparenthesized comma in an initializer list); this change was made by
N2829.  Note that this only applies to assert, not to other macros
specified in the C standard with particular numbers of arguments.

Implement this support in glibc.  This change is only for C; C++ would
need a separate change to its separate assert implementations.  It's
also applied only in C23 mode.  It depends on support for (C99)
variadic macros, and also (in order to detect calls where more than
one expression is passed, via an unevaluated function call) a C99
boolean type.  These requirements are encapsulated in the definition
of __ASSERT_VARIADIC.  Tests with -std=c99 and -std=gnu99 (using
implementations continue to work.

I don't think we have a way in the glibc testsuite to validate that
passing more than one expression as an argument does produce the
desired error.

Tested for x86_64.

The C2y function uimaxabs has been renamed to umaxabs.  Implement this
change in glibc, keeping a compat symbol under the old name, copying
the test to test the new name and changing the old test to test the
compat symbol.  Jakub has done the corresponding change to the
built-in function in GCC.

Tested for x86_64 and x86.

Add the C23 memalignment function (query the alignment of a pointer)
to glibc.

Given how simple this operation is, it would make sense for compilers
to inline calls to this function, but I'm treating that as a compiler
matter (compilers should add it as a built-in function) rather than
adding an inline version to glibc headers (although such an inline
version would be reasonable as well).  I've filed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122117 for this feature
in GCC.

Tested for x86_64 and x86.

Add the C23 memset_explicit function to glibc.  Everything here is
closely based on the approach taken for explicit_bzero.  This includes
the bits that relate to internal uses of explicit_bzero within glibc
(although we don't currently have any such internal uses of
memset_explicit), and also includes the nonnull attribute (when we
move to nonnull_if_nonzero for various functions following C2y, this
function should be included in that change).

The function is declared both for __USE_MISC and for __GLIBC_USE (ISOC23)
(so by default not just for compilers defaulting to C23 mode).

Tested for x86_64 and x86.