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 53807741fb44edb8e7c094cb5e7d4ff4e92a6ec1 added a configure check
for 64-bit atomic operations that were not previously enabled on some
32-bit ABIs.

However, the NPTL semaphore code casts a sem_t to a new_sem and issues
a 64-bit atomic operation for __HAVE_64B_ATOMICS.  Since sem_t has
32-bit alignment on 32-bit architectures, this prevents the use of
64-bit atomics even if the ABI supports them.

Assume 64-bit atomic support from __WORDSIZE, which maps to how glibc
defines it before the broken change.  Also rename __HAVE_64B_ATOMICS
to USE_64B_ATOMICS to define better the flag meaning.

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

Reviewed-by: Wilco Dijkstra  <Wilco.Dijkstra@arm.com>

The definition of once_flag conflicts with std::once_flag in
if “using namespace std;” is active.

Updates commit a7ddbf456d97ac8d1aa7afd735e196a1488bd874
("Add once_flag, ONCE_FLAG_INIT and call_once to stdlib.h for C23").

Suggested-by: Jonathan Wakely <jwakely@redhat.com>
Reviewed-by: Collin Funk <collin.funk1@gmail.com>

The count_leading_zeros is not used anymore, so there is no need to
provide the table for possible usage.  The hppa already provides
the compat symbol on libgcc-compat.c.

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

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

Reviewed-by: H.J. Lu <hjl.tools@gmail.com>
Reviewed-by: Collin Funk <collin.funk1@gmail.com>

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.

clang 20 adds both __INT64_C and __UINT64_C as builtins, but different
than gcc it does not undef them in its stdint wrapper.

Reviewed-by: H.J. Lu <hjl.tools@gmail.com>

It is not required on current supported gcc.

Reviewed-by: Florian Weimer <fweimer@redhat.com>

A late change in C23, the resolution to CD2 comment GB-108, specified
that <inttypes.h> macros such as PRId8 expand to formats such that,
when an argument is passed in the promoted type that isn't
representable in the original type such as int8_t corresponding to the
format, it gets converted to that type before printing.  (Previously,
the proper handling of such arguments was unclear; the case of direct
use of formats such as %hhd was clarified earlier in C23 development,
and had been fixed in glibc in 2006.)  Implement the change to use
formats such as "hhd" for the affected macros, with associated tests.

Tested for x86_64 and x86.