GCC gives a -Wignored-attributes warning when a class template is
instantiated with a type that has an aligned(n) attribute. Specifically,
cris-elf uses 'typedef int __attribute_((__aligned(4))) _Atomic_word;'
and so compiling libstdc++ headers gives:
warning: ignoring attributes on template argument ‘int’ [-Wignored-attributes]

This commit reduces four occurrences of make_unsigned<_Atomic_word> into
two, one in bits/shared_ptr_base.h and one in ext/atomicity.h, and uses
diagnostic pragmas around the two remaining uses to avoid the warnings.
Because the unsigned type might have lost the alignment of _Atomic_word
that is needed for atomic ops (at least on cris-elf), the unsigned type
should only be used for plain non-atomic arithmetic. To prevent misuse,
it's defined as a private type in _Sp_counted_base, and is defined and
then undefined as a macro in ext/atomicity.h, so that it's not usable
after __exchange_and_add_single and __atomic_add_single have been
defined.

We also get a warning from instantiating __int_traits<_Atomic_word> in
shared_ptr_base.h which can be avoided by calculating the maximum signed
value from the maximum unsigned value.

libstdc++-v3/ChangeLog:

	PR libstdc++/122172
	* include/bits/shared_ptr_base.h (_Sp_counted_base): Define
	_Unsigned_count_type for make_unsigned<_Atomic_word>.
	Replace __int_traits<_Atomic_word> with equivalent expression.
	* include/ext/atomicity.h (_GLIBCXX_UNSIGNED_ATOMIC_WORD):
	Define macro for unsigned type to use for arithmetic.
	(__exchange_and_add_single, __atomic_add_single): Use it.

Reviewed-by: Hans-Peter Nilsson <hp@axis.com>

This avoids -Wmaybe-uninitialized warnings.

libstdc++-v3/ChangeLog:

	* include/ext/ropeimpl.h (rope::_S_fetch): Initialize variable.

The standard requires that std::atomic<integral-type>::fetch_add does
not have undefined behaviour for signed overflow, instead it wraps like
unsigned integers. The compiler ensures this is true for the atomic
built-ins that std::atomic uses, but it's not currently true for the
__gnu_cxx::__exchange_and_add and __gnu_cxx::__atomic_add functions
defined in libstdc++, which operate on type _Atomic_word.

For the inline __exchange_and_add_single function (used when there's
only one thread in the process), we can copy the value to an unsigned
long and do the addition on that, then assign it back to the
_Atomic_word variable.

The __exchange_and_add in config/cpu/generic/atomicity_mutex/atomicity.h
locks a mutex and then performs exactly the same steps as
__exchange_and_add_single.  Calling __exchange_and_add_single instead of
duplicating the code benefits from the fix just made to
__exchange_and_add_single.

For the remaining config/cpu/$arch/atomicity.h implementations, they
either use inline assembly which uses wrapping instructions (so no
changes needed), or we can fix them by compiling with -fwrapv.

After ths change, UBsan no longer gives an error for:

  _Atomic_word i = INT_MAX;
  __gnu_cxx::__exchange_and_add_dispatch(&i, 1);

/usr/include/c++/14/ext/atomicity.h:85:12: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'

libstdc++-v3/ChangeLog:

	PR libstdc++/121148
	* config/cpu/generic/atomicity_mutex/atomicity.h
	(__exchange_and_add): Call __exchange_and_add_single.
	* include/ext/atomicity.h (__exchange_and_add_single): Use an
	unsigned type for the addition.
	* libsupc++/Makefile.am (atomicity.o): Compile with -fwrapv.
	* libsupc++/Makefile.in: Regenerate.

Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>

During the tests mentioned in
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/692482.html
(but dunno why I haven't noticed it back in August but only when testing
https://gcc.gnu.org/pipermail/gcc-patches/2025-September/694527.html )
I've noticed two ext header problems.
One is that #include <ext/pointer.h> got broken with the
r13-3037-g18f176d0b25591e28 change and since then is no longer
self-contained, as it includes iosfwd only if _GLIBCXX_HOSTED is defined
but doesn't actually include bits/c++config.h to make sure it is defined,
then includes a bunch of headers which do include bits/c++config.h and
finally uses in #if _GLIBCXX_HOSTED guarded code what is declared in iosfwd.
The other problem is that ext/cast.h is also not a self-contained header,
but that one has
/** @file ext/cast.h
 *  This is an internal header file, included by other library headers.
 *  Do not attempt to use it directly. @headername{ext/pointer.h}
 */
comment, so I think we just shouldn't include it in extc++.h and let
ext/pointer.h include it.

2025-09-08  Jakub Jelinek  <jakub@redhat.com>

	PR libstdc++/121827
	* include/precompiled/extc++.h: Don't include ext/cast.h which is an
	internal header.
	* include/ext/pointer.h: Include bits/c++config.h before
	#if _GLIBCXX_HOSTED.

Since LWG 3828 (included in C++23) implementations are allowed to have
extended integer types that are wider than intmax_t. This means we no
longer have to make is_integral_v<__int128> false for strict -std=c++23
mode, removing the confusing inconsistency with -std=gnu++23 (where
is_integral_v<__int128> is true).

This change makes __int128 a true integral type for all modes, treating
LWG 3828 as a DR for previous standards. Most of the change just
involves removing special cases where we wanted to treat __int128 and
unsigned __int128 as integral types even when is_integral_v was false.

There are still some preprocessor conditionals needed, because on some
targets the compiler defines the macro __GLIBCXX_TYPE_INT_N_0 as
__int128 in non-strict modes. Because we define explicit specializations
of templates such as is_integral for all the INT_N types, we already
have a specialization of is_integral<__int128> in non-strict modes, and
so to avoid a redefinition we only must only define
is_integral<__int128> for strict modes.

libstdc++-v3/ChangeLog:

	PR libstdc++/96710
	* include/bits/cpp_type_traits.h (__is_integer): Define explicit
	specializations for __int128.
	(__memcpyable_integer): Remove explicit specializations for
	__int128.
	* include/bits/iterator_concepts.h (incrementable_traits):
	Likewise.
	(__is_signed_int128, __is_unsigned_int128, __is_int128): Remove.
	(__is_integer_like, __is_signed_integer_like): Remove check for
	__int128.
	* include/bits/max_size_type.h: Remove all uses of __is_int128
	in constraints.
	* include/bits/ranges_base.h (__to_unsigned_like): Remove
	overloads for __int128.
	(ranges::ssize): Remove special case for __int128.
	* include/bits/stl_algobase.h (__size_to_integer): Define
	__int128 overloads for strict modes.
	* include/ext/numeric_traits.h (__is_integer_nonstrict): Remove
	explicit specializations for __int128.
	* include/std/charconv (to_chars): Define overloads for
	__int128.
	* include/std/format (__format::make_unsigned_t): Remove.
	(__format::to_chars): Remove.
	* include/std/limits (numeric_limits): Define explicit
	specializations for __int128.
	* include/std/type_traits (__is_integral_helper): Likewise.
	(__make_unsigned, __make_signed): Likewise.

Reviewed-by: Patrick Palka <ppalka@redhat.com>

libstdc++-v3/ChangeLog:

	PR libstdc++/81806
	* include/ext/pb_ds/detail/bin_search_tree_/split_join_fn_imps.hpp
	(split_finish): Use maintained size, instead of calling
	std::distance.

libstdc++-v3/ChangeLog:

	* include/ext/pb_ds/detail/rb_tree_map_/node.hpp
	(rb_tree_node_::size_type): New typedef.
	(rb_tree_node_::m_subtree_size): New field.
	* include/ext/pb_ds/detail/splay_tree_/node.hpp
	(splay_tree_node_::size_type): New typedef.
	(splay_tree_node_::m_subtree_size): New field.
	* include/ext/pb_ds/detail/bin_search_tree_/bin_search_tree_.hpp
	(PB_DS_BIN_TREE_NAME::update_subtree_size): Declare new member
	function.
	* include/ext/pb_ds/detail/bin_search_tree_/rotate_fn_imps.hpp
	(update_subtree_size): Define.
	(apply_update, update_to_top): Call update_subtree_size.

libstdc++-v3/ChangeLog:

	* include/ext/pb_ds/detail/bin_search_tree_/insert_fn_imps.hpp
	(insert_leaf_new, insert_imp_empty): remove redundant statements.

Currently the GLIBCXX_ENABLE_ATOMIC_BUILTINS macro checks for a variety
of __atomic built-ins for bool, short and int. If all those checks pass,
then it defines _GLIBCXX_ATOMIC_BUILTINS and uses the definitions from
config/cpu/generic/atomicity_builtins/atomicity.h for the non-inline
versions of __exchange_and_add and __atomic_add that get compiled into
libsupc++.

However, the config/cpu/generic/atomicity_builtins/atomicity.h
definitions only depend on __atomic_fetch_add not on
__atomic_test_and_set or __atomic_compare_exchange. And they only
operate on a variable of type _Atomic word, which is not necessarily one
of bool, short or int (e.g. for sparcv9 _Atomic_word is 64-bit long).

This means that for a target where _Atomic_word is int but there are no
1-byte or 2-byte atomic instructions, GLIBCXX_ENABLE_ATOMIC_BUILTINS
will fail the checks for bool and short and not define the macro
_GLIBCXX_ATOMIC_BUILTINS. That means that we will use a single global
mutex for reference counting in the COW std::string and std::locale,
even though we could use __atomic_fetch_add to do it lock-free.

This commit removes most of the GLIBCXX_ENABLE_ATOMIC_BUILTINS checks,
so that it only checks __atomic_fetch_add on _Atomic_word. The macro
defined by GLIBCXX_ENABLE_ATOMIC_BUILTINS is renamed from
_GLIBCXX_ATOMIC_BUILTINS to _GLIBCXX_ATOMIC_WORD_BUILTINS to better
reflect what it really means. This will enable the inline versions of
__exchange_and_add and __atomic_add for more targets. This is not an ABI
change, because targets which didn't previously use the inline
definitions of those functions made non-inlined calls to the functions
in the library. If the definitions of those functions now start using
atomics, that doesn't change the semantics for the code calling those
functions.

On affected targets, new code compiled after this change will see the
_GLIBCXX_ATOMIC_WORD_BUILTINS macro and so will use the always-inline
versions of __exchange_and_add and __atomic_add, which use
__atomic_fetch_add directly. That is also compatible with older code
which still calls the non-inline definitions, because those non-inline
definitions now also use __atomic_fetch_add.

The only configuration where this could be an ABI change is for a target
which previously defined _GLIBCXX_ATOMIC_BUILTINS (because all the
atomic built-ins for bool, short and int are supported), but which
defines _Atomic_word to some other type for which __atomic_fetch_add is
/not/ supported. Such a target would have called the inline functions
using __atomic_fetch_add, which would actually have depended on
libatomic (which is what the configure checks were supposed to
prevent!).  After this change, that target would not define the new
macro, _GLIBCXX_ATOMIC_WORD_BUILTINS, and so would make non-inline calls
into the library where __exchange_and_add and __atomic_add would use the
global mutex. That would be an ABI break. I don't consider that a
realistic scenario, because it wouldn't have made any sense to define
_Atomic_word to a wider type than int, when doing so would have required
libatomic to make libstdc++.so work. Surely such a target would have
just used int for its _Atomic_word type.

The GLIBCXX_ENABLE_BACKTRACE macro currently uses the
glibcxx_ac_atomic_int variable defined by the checks that this commit
removes from GLIBCXX_ENABLE_ATOMIC_BUILTINS. That wasn't a good check
anyway, because libbacktrace actually depends on atomic loads+stores for
pointers as well as int, and for atomic stores for size_t. This commit
replaces the glibcxx_ac_atomic_int check with a proper test for all the
required atomic operations on all three of int, void* and size_t. This
ensures that the libbacktrace code used for std::stacktrace will either
use native atomics, or implement those loads and stores only in terms of
__sync_bool_compare_and_swap (possibly requiring that to come from
libatomic or elsewhere).

libstdc++-v3/ChangeLog:

	PR libstdc++/70560
	PR libstdc++/119667
	* acinclude.m4 (GLIBCXX_ENABLE_ATOMIC_BUILTINS): Only check for
	__atomic_fetch_add on _Atomic_word. Define new macro
	_GLIBCXX_ATOMIC_WORD_BUILTINS and stop defining macro
	_GLIBCXX_ATOMIC_BUILTINS.
	(GLIBCXX_ENABLE_BACKTRACE): Check for __atomic_load_n and
	__atomic_store_n on int, void* and size_t.
	* config.h.in: Regenerate.
	* configure: Regenerate.
	* configure.host: Fix typo in comment.
	* include/ext/atomicity.h (__exchange_and_add, __atomic_add):
	Depend on _GLIBCXX_ATOMIC_WORD_BUILTINS macro instead of old
	_GLIBCXX_ATOMIC_BUILTINS macro.