libstdc++-v3/ChangeLog:

	* include/debug/safe_local_iterator.h (_GLIBCXX_DEBUG_VERIFY_OPERANDS):
	Add parentheses to avoid -Wparentheses warning.

Inserting an empty range into a std::deque results in undefined calls to
either std::copy, std::copy_backward, std::move, or std::move_backward.
We call those algos with invalid arguments where the output range is the
same as the input range, e.g.  std::copy(first, last, first) which
violates the preconditions for the algorithms.

This fix simply returns early if there's nothing to insert. Most callers
already ensure that we don't even call _M_range_insert_aux with an empty
range, but some callers don't. Rather than checking for n == 0 in each
of the callers, this just does the check once and uses __builtin_expect
to treat empty insertions as unlikely.

libstdc++-v3/ChangeLog:

	PR libstdc++/118035
	* include/bits/deque.tcc (_M_range_insert_aux): Return
	immediately if inserting an empty range.
	* testsuite/23_containers/deque/modifiers/insert/118035.cc: New
	test.

Currently the _M_bucket members are left uninitialized for
default-initialized local iterators, and then copy construction copies
indeterminate values. We should just ensure they're initialized on
construction.

Setting them to zero makes default-initialization consistent with
value-initialization and avoids indeterminate values.

For the _Local_iterator_base<..., false> specialization we preserve the
existing behaviour of setting _M_bucket_count to -1 in the default
constructor, as a sentinel value to indicate there's no hash object
present.

libstdc++-v3/ChangeLog:

	* include/bits/hashtable_policy.h (_Local_iterator_base): Use
	default member-initializers.

This file is only for C++11 and later, so replace typedefs with
alias-declarations for clarity. Also remove redundant std::
qualification on size_t, ptrdiff_t etc.

We can also remove the result_type, first_argument_type and
second_argument_type typedefs from the range hashers. We don't need
those types to follow the C++98 adaptable function object protocol.

libstdc++-v3/ChangeLog:

	* include/bits/hashtable_policy.h: Replace typedefs with
	alias-declarations. Remove redundant std:: qualification.
	(_Mod_range_hashing, _Mask_range_hashing): Remove adaptable
	function object typedefs.

The fix for PR libstdc++/56267 (relating to the lifetime of the hash
object stored in a local iterator) has undefined behaviour, as it relies
on being able to call a member function on an empty object that never
started its lifetime. Although the member function probably doesn't care
about the empty object's state, this is still technically undefined
because there is no object of that type at that address. It's also
possible that the hash object would have a stricter alignment than the
_Hash_code_storage object, so that the reinterpret_cast would produce a
misaligned pointer.

This fix replaces _Local_iterator_base's _Hash_code_storage base-class
with a new class template containing a potentially-overlapping (i.e.
[[no_unique_address]]) union member.  This means that we always have
storage of the correct type, and it can be initialized/destroyed when
required. We no longer need a reinterpret_cast that gives us a pointer
that we should not dereference.

It would be nice if we could just use a union containing the _Hash
object as a data member of _Local_iterator_base, but that would be an
ABI change. The _Hash_code_storage that contains the _Hash object is the
first base-class, before the _Node_iterator_base base-class. Making the
union a data member of _Local_iterator_base would make it come after the
_Node_iterator_base base instead of before it, altering the layout.

Since we're changing _Hash_code_storage anyway, we can replace it with a
new class template that stores the _Hash object itself in the union,
rather than a _Hash_code_base that holds the _Hash. This removes an
unnecessary level of indirection in the class hierarchy. This change
requires the effects of _Hash_code_base::_M_bucket_index to be inlined
into the _Local_iterator_base::_M_incr function, but that's easy.

We don't need separate specializations of _Hash_obj_storage for an empty
hash function and a non-empty one. Using [[no_unique_address]] gives us
an empty base-class when possible.

libstdc++-v3/ChangeLog:

	* include/bits/hashtable_policy.h (_Hash_code_storage): Remove.
	(_Hash_obj_storage): New class template. Store the hash
	function as a union member instead of using a byte buffer.
	(_Local_iterator_base): Use _Hash_obj_storage instead of
	_Hash_code_storage, adjust members that construct and destroy
	the hash object.
	(_Local_iterator_base::_M_incr): Calculate bucket index.

The main change here is using [[no_unique_address]] instead of the Empty
Base-class Optimization. Using the attribute allows us to use data
members instead of base-classes. That simplifies the inheritance
hierarchy, which means less work for the compiler. It also means that
ADL has fewer associated classes and associated namespaces to consider,
further reducing the work the compiler has to do.

Reducing the differences between the _Hashtable_ebo_helper primary
template and the partial specialization means we no longer need to use
member functions to access the stored object, because it's now always a
data member called _M_obj.  This means we can also remove a number of
other helper functions that were using those member functions to access
the object, for example we can swap the _Hash and _Equal objects
directly in _Hashtable::swap instead of calling _Hashtable_base::_M_swap
which then calls _Hash_code_base::_M_swap.

Although [[no_unique_address]] would allow us to reduce the size for
empty types that are also 'final', doing so would be an ABI break
because those types were previously excluded from using the EBO. So we
still need the _Hashtable_ebo_helper class template and a partial
specialization, so that we only use the attribute under exactly the same
conditions as we previously used the EBO. This could be avoided with a
non-standard [[no_unique_address(expr)]] attribute that took a boolean
condition, or with reflection and token sequence injection, but we don't
have either of those things.

Because _Hashtable_ebo_helper is no longer used as a base-class we don't
need to disambiguate possible identical bases, so it doesn't need an
integral non-type template parameter.

libstdc++-v3/ChangeLog:

	* include/bits/hashtable.h (_Hashtable::swap): Swap hash
	function and equality predicate here. Inline allocator swap
	instead of using __alloc_on_swap.
	* include/bits/hashtable_policy.h (_Hashtable_ebo_helper):
	Replace EBO with no_unique_address attribute. Remove NTTP.
	(_Hash_code_base): Replace base class with data member using
	no_unique_address attribute.
	(_Hash_code_base::_M_swap): Remove.
	(_Hash_code_base::_M_hash): Remove.
	(_Hashtable_base): Replace base class with data member using
	no_unique_address attribute.
	(_Hashtable_base::_M_swap): Remove.
	(_Hashtable_alloc): Replace base class with data member using
	no_unique_address attribute.

The union members I used in the new _Node types for fancy pointers only
work for value types that are trivially default constructible. This
change replaces the anonymous union with a named union so it can be
given a default constructor and destructor, to leave the variant member
uninitialized.

This also fixes the incorrect macro names in the alloc_ptr_ignored.cc
tests as pointed out by François, and fixes some std::list pointer
confusions that the fixed alloc_ptr_ignored.cc test revealed.

libstdc++-v3/ChangeLog:

	PR libstdc++/57272
	* include/bits/forward_list.h (__fwd_list::_Node): Add
	user-provided special member functions to union.
	* include/bits/stl_list.h (__list::_Node): Likewise.
	(_Node_base::_M_hook, _Node_base::swap): Use _M_base() instead
	of std::pointer_traits::pointer_to.
	(_Node_base::_M_transfer): Likewise. Add noexcept.
	(_List_base::_M_put_node): Use 'if constexpr' to avoid using
	pointer_traits::pointer_to when not necessary.
	(_List_base::_M_destroy_node): Fix parameter to be the pointer
	type used internally, not the allocator's pointer.
	(list::_M_create_node): Likewise.
	* testsuite/23_containers/forward_list/requirements/explicit_instantiation/alloc_ptr.cc:
	Check explicit instantiation of non-trivial value type.
	* testsuite/23_containers/list/requirements/explicit_instantiation/alloc_ptr.cc:
	Likewise.
	* testsuite/23_containers/forward_list/requirements/explicit_instantiation/alloc_ptr_ignored.cc:
	Fix macro name.
	* testsuite/23_containers/list/requirements/explicit_instantiation/alloc_ptr_ignored.cc:
	Likewise.

libstdc++-v3/ChangeLog:

	* include/c_compatibility/wchar.h (fgetwc): Remove duplicate
	using-declaration.

Use a local reference for the (now possibly lifetime extended) result of
*__first so that we copy it only when necessary.

	PR libstdc++/112349

libstdc++-v3/ChangeLog:

	* include/bits/ranges_algo.h (__min_fn::operator()): Turn local
	object __tmp into a reference.
	* include/bits/ranges_util.h (__max_fn::operator()): Likewise.
	* testsuite/25_algorithms/max/constrained.cc (test04): New test.
	* testsuite/25_algorithms/min/constrained.cc (test04): New test.

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>

I noticed a -Wmaybe-uninitialized warning for this function, which turns
out to be correct. If the caller passes a valid std::ios_base::seekdir
value then there's no problem, but if they pass std::seekdir(999) then
we don't initialize the __base variable before adding it to __off.

Rather than initialize it to an arbitrary value, we should return an
error.

Also add [[unlikely]] attributes to the paths that return an error.

libstdc++-v3/ChangeLog:

	* include/std/spanstream (basic_spanbuf::seekoff): Return an
	error for invalid seekdir values.

Although this should never make a difference for sensible code, we
should really make the expression in the noexcept-specifier match the
expression in the function body.

libstdc++-v3/ChangeLog:

	* include/bits/ranges_cmp.h (not_equal_to): Make order of
	expressions in noexcept-specifier match the body.
	* testsuite/20_util/function_objects/range.cmp/not_equal_to.cc:
	Check noexcept.

libstdc++-v3/ChangeLog:

	* include/bits/regex.tcc: Fix -Wsign-compare warning.

libstdc++-v3/ChangeLog:

	* include/pstl/parallel_backend_tbb.h (__merge_func): Fix order
	of mem-initializers.

libstdc++-v3/ChangeLog:

	* testsuite/26_numerics/random/random_device/entropy.cc: Fix
	indentation to avoid -Wmisleading-indentation warning.

libstdc++-v3/ChangeLog:

	* testsuite/23_containers/unordered_map/modifiers/reserve.cc:
	Cast to size_t to fix -Wsign-compare warning.
	* testsuite/23_containers/unordered_set/hash_policy/71181.cc:
	Likewise.
	* testsuite/23_containers/unordered_set/insert/move_range.cc:
	Likewise.

libstdc++-v3/ChangeLog:

	* include/bits/hashtable_policy.h (_Local_iterator_base): Fix
	-Wsign-compare warnings.

libstdc++-v3/ChangeLog:

	* src/c++17/fs_dir.cc: Fix typo in comment.

Because of PR c++/85944 we have several bugs where _GLIBCXX_DEBUG causes
errors for constexpr code. Although Bug 117966 could be fixed by
avoiding redundant debug checks in std::span, and Bug 106212 could be
fixed by avoiding redundant debug checks in std::array, there are many
more cases where similar __glibcxx_requires_valid_range checks fail to
compile and removing the checks everywhere isn't desirable.

This just disables the __gnu_debug::__check_singular(T*) check during
constant evaluation. Attempting to dereference a null pointer will
certainly fail during constant evaluation (if it doesn't fail then it's
a compiler bug and not the library's problem). Disabling this check
during constant evaluation shouldn't do any harm.

libstdc++-v3/ChangeLog:

	PR libstdc++/109517
	PR libstdc++/109976
	* include/debug/helper_functions.h (__valid_range_aux): Treat
	all input iterator ranges as valid during constant evaluation.

As PR c++/106212 shows, the Debug Mode checks cause a compilation error
for equality comparisons involving std::array prvalues in constant
expressions. Those Debug Mode checks are redundant when
comparing two std::array objects, because we already know we have a
valid range. We can also avoid the unnecessary step of using
std::__niter_base to do __normal_iterator unwrapping, which isn't needed
because our std::array iterators are just pointers. Using
std::__equal_aux1 instead of std::equal avoids the redundant checks in
std::equal and std::__equal_aux.

libstdc++-v3/ChangeLog:

	PR libstdc++/106212
	* include/std/array (operator==): Use std::__equal_aux1 instead
	of std::equal.
	* testsuite/23_containers/array/comparison_operators/106212.cc:
	New test.

As PR c++/117966 shows, the Debug Mode checks cause a compilation error
for a global constexpr std::span. Those debug checks are redundant when
constructing from an array or a range, because we already know we have a
valid range and we know its size. Instead of delegating to the
std::span(contiguous_iterator, contiguous_iterator) constructor, just
initialize the data members directly.

libstdc++-v3/ChangeLog:

	PR libstdc++/117966
	* include/std/span (span(T (&)[N])): Do not delegate to
	constructor that performs redundant checks.
	(span(array<T, N>&), span(const array<T, N>&)): Likewise.
	(span(Range&&), span(const span<T, N>&)): Likewise.
	* testsuite/23_containers/span/117966.cc: New test.

This was approved in Wrocław as LWG 3900, so that passing an incorrect
argument intended as an allocator will be ill-formed, instead of
silently ignored.

This also renames the template parameters and function parameters for
the allocators, to align with the names in the standard. I found it too
confusing to have a parameter _Alloc which doesn't correspond to Alloc
in the standard. Rename _Alloc to _Allocator (which the standard calls
Allocator) and rename _Na to _Alloc (which the standard calls Alloc).

libstdc++-v3/ChangeLog:

	* include/std/generator (_Promise_alloc): Rename template
	parameter. Use __alloc_rebind to rebind allocator.
	(_Promise_alloc::operator new): Replace constraints with a
	static_assert in the body. Rename allocator parameter.
	(_Promise_alloc<void>::_M_allocate): Rename allocator parameter.
	Use __alloc_rebind to rebind allocator.
	(_Promise_alloc<void>::operator new): Rename allocator
	parameter.
	* testsuite/24_iterators/range_generators/alloc.cc: New test.
	* testsuite/24_iterators/range_generators/lwg3900.cc: New test.

Reviewed-by: Arsen Arsenović <arsen@aarsen.me>

This was just approved in Wrocław.

libstdc++-v3/ChangeLog:

	* include/std/ostream (println): Pass stream's locale to
	std::format, as per LWG 4088.
	* testsuite/27_io/basic_ostream/print/1.cc: Check std::println
	with custom locale. Remove unused brit_punc class.

Check the __glibcxx_polymorphic_allocator macro instead of just checking
whether __cplusplus > 201703L.

libstdc++-v3/ChangeLog:

	* include/bits/memory_resource.h (polymoprhic_allocator): Use
	feature test macro for P0339R6 features.

This patch implements P2865R5 by promoting the warning to permerror in
C++26 only.

In C++20 we should warn even without -Wall.  Jason fixed this in r15-5713
but let's add a test that doesn't use -Wall.

This caused a FAIL in conditionally_borrowed.cc because we end up
comparing two array types in equality_comparable_with ->
__weakly_eq_cmp_with.  That could be fixed in libstc++, perhaps by
adding std::decay in the appropriate place.

	PR c++/117788

gcc/c-family/ChangeLog:

	* c-warn.cc (do_warn_array_compare): Emit a permerror in C++26.

gcc/cp/ChangeLog:

	* typeck.cc (cp_build_binary_op) <case EQ_EXPR>: Don't check
	warn_array_compare.  Check tf_warning_or_error instead of just
	tf_warning.  Maybe return an error_mark_node in C++26.
	<case LE_EXPR>: Likewise.

gcc/testsuite/ChangeLog:

	* c-c++-common/Warray-compare-1.c: Expect an error in C++26.
	* c-c++-common/Warray-compare-3.c: Likewise.
	* c-c++-common/Warray-compare-4.c: New test.
	* c-c++-common/Warray-compare-5.c: New test.
	* g++.dg/warn/Warray-compare-1.C: New test.

libstdc++-v3/ChangeLog:

	* testsuite/std/ranges/adaptors/conditionally_borrowed.cc: Add a
	FIXME, adjust.

Reviewed-by: Jason Merrill <jason@redhat.com>

This reverts r15-6060-ge4a0157c2397c9 so that __is_bitwise_relocatable
depends only on is_trivial. To avoid the deprecation warnings for C++26,
use the __is_trivial built-in directly instead of std::is_trivial.

We need to be sure that the type is trivially copyable, not just
trivially constructible and trivially assignable. Otherwise we get
-Wclass-memaccess diagnostics for e.g. std::vector<std::pair<A*, B*>>.
We could add is_trivially_copyable to the conditions, but this isn't
really an appropriate change for stage 3 anyway (it affects all modes
from C++11 upwards). Just revert to using is_trivial, and we can revisit
the condition for GCC 16.

libstdc++-v3/ChangeLog:

	* include/bits/stl_uninitialized.h (__is_bitwise_relocatable):
	Revert to depending on is_trivial.

This actually implements P3247R2 by deprecating the is_trivial type
trait.

libstdc++-v3/ChangeLog:

	* include/std/type_traits: Deprecate is_trivial and
	is_trivial_v.
	* include/experimental/type_traits: Suppress the deprecation
	warning.
	* testsuite/20_util/is_trivial/requirements/explicit_instantiation.cc:
	Amend the test to suppress the deprecation warning.
	* testsuite/20_util/is_trivial/requirements/typedefs.cc:
	Likewise.
	* testsuite/20_util/is_trivial/value.cc: Likewise.
	* testsuite/20_util/variable_templates_for_traits.cc: Likewise.
	* testsuite/experimental/type_traits/value.cc: Likewise.
	* testsuite/18_support/max_align_t/requirements/2.cc: Update the
	test with P3247R2's new wording.

Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>

In preparation for the deprecation of is_trivial (P3247R2).
Mostly a mechanical exercise, replacing is_trivial with
is_trivially_copyable and/or is_trivially_default_constructible
depending on the cases.

libstdc++-v3/ChangeLog:

	* testsuite/20_util/specialized_algorithms/uninitialized_copy/102064.cc:
	Port away from is_trivial.
	* testsuite/20_util/specialized_algorithms/uninitialized_copy_n/102064.cc:
	Likewise.
	* testsuite/20_util/specialized_algorithms/uninitialized_default/94540.cc:
	Likewise.
	* testsuite/20_util/specialized_algorithms/uninitialized_default_n/94540.cc:
	Likewise.
	* testsuite/20_util/specialized_algorithms/uninitialized_fill/102064.cc:
	Likewise.
	* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/102064.cc:
	Likewise.
	* testsuite/20_util/specialized_algorithms/uninitialized_value_construct/94540.cc:
	Likewise.
	* testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/94540.cc:
	Likewise.
	* testsuite/23_containers/vector/cons/94540.cc: Likewise.
	* testsuite/25_algorithms/copy/move_iterators/69478.cc:
	Likewise.
	* testsuite/25_algorithms/copy_backward/move_iterators/69478.cc:
	Likewise.
	* testsuite/25_algorithms/move/69478.cc: Likewise.
	* testsuite/25_algorithms/move_backward/69478.cc: Likewise.
	* testsuite/25_algorithms/rotate/constrained.cc: Likewise.
	* testsuite/25_algorithms/rotate_copy/constrained.cc: Likewise.

Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>

In preparation for the deprecation of is_trivial (P3247R2).
The rangified uninitialized_* specialized memory algorithms have code
paths where they call the non-uninitialized versions, because the latter
are usually optimized. The detection in these code paths uses is_trivial;
port it away from it towards more specific checks.

The detection for the copy/move algorithms was suspicious: it checked
that the output type was trivial, and that assignment from the input
range reference type was nothrow. If so, the algorithm would copy/move
assign (by calling the ranges::copy/move algorithms) instead of
constructing elements. I think this is off because:

1) the constructor that would be called by the algorithm (which may be
   neither a copy or a move constructor) wasn't checked. If that
   constructor isn't trivial the caller might detect that we're not
   calling it, and that goes against the algorithms' specifications.
2) a nothrow assignment is necessary but not sufficient, as again we
   need to check for triviality, or the caller can detect we're calling
   an assignment operator we were never meant to be calling from these
   algorithms.

Therefore I've amended the respective detections.

libstdc++-v3/ChangeLog:

	* include/bits/ranges_uninitialized.h: port some if
	constexpr away from is_trivial, and towards more specific
	detections instead.

Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>

In preparation for the deprecation of is_trivial (P3247R2).
"bitwise relocation" (or "trivial relocation" à la P1144/P2786)
doesn't need the full-fledged notion of triviality, just checking for a
trivial move constructor and a trivial destructor is sufficient.

libstdc++-v3/ChangeLog:

	* include/bits/stl_uninitialized.h: Amended the
	__is_bitwise_relocatable type trait.

Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>

In preparation for the deprecation of is_trivial (P3247R2).
Unfortunately I am unable to fully understand what aspect of triviality
seems to matter for these algorithms, so I just ported is_trivial to its
direct equivalent (trivially copyable + trivially default
constructible.)

libstdc++-v3/ChangeLog:

	* include/pstl/algorithm_impl.h (__remove_elements): Port away
	from is_trivial.
	(__pattern_inplace_merge): Likewise.
	* include/pstl/glue_memory_impl.h (uninitialized_copy): Likewise.
	(uninitialized_copy_n): Likewise.
	(uninitialized_move): Likewise.
	(uninitialized_move_n): Likewise.
	(uninitialized_default_construct): Likewise.
	(uninitialized_default_construct_n): Likewise.
	(uninitialized_value_construct): Likewise.
	(uninitialized_value_construct_n): Likewise.
	* testsuite/20_util/specialized_algorithms/pstl/uninitialized_construct.cc:
	Likewise.
	* testsuite/20_util/specialized_algorithms/pstl/uninitialized_copy_move.cc:
	Likewise.
	* testsuite/20_util/specialized_algorithms/pstl/uninitialized_fill_destroy.cc:
	Likewise.
	* testsuite/25_algorithms/pstl/alg_modifying_operations/partition.cc:
	Likewise.

Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>

In preparation for the deprecation of is_trivial (P3247R2), stop using
it from std::string_view. Also, add the same detection to std::string
(described in [strings.general]/2).

libstdc++-v3/ChangeLog:

	* include/bits/basic_string.h: Add a static_assert on the
	char-like type.
	* include/std/string_view: Port away from is_trivial.

Signed-off-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>

On macOS and FreeBSD the read(2) system call can return EINVAL for large
sizes, so limit the maximum that we try to read. The calling code in
basic_filebuf::xsgetn will loop until it gets the size it wants, so we don't
need to loop in basic_file::xsgetn, just limit the maximum size.

libstdc++-v3/ChangeLog:

	PR libstdc++/102259
	* config/io/basic_file_stdio.cc (basic_file::xsgetn): Limit n to
	_GLIBCXX_MAX_READ_SIZE if that macro is defined.
	* config/os/bsd/darwin/os_defines.h (_GLIBCXX_MAX_READ_SIZE):
	Define to INT_MAX-1.
	* config/os/bsd/freebsd/os_defines.h (_GLIBCXX_MAX_READ_SIZE):
	Likewise.

This was removed by P2868R3, voted into the C++26 draft at the November
2023 meeting in Kona. We've had a deprecated warning in place for three
years.

libstdc++-v3/ChangeLog:

	* include/bits/allocator.h (allocator::is_always_equal): Do not
	define for C++26.
	(allocator<void>::is_always_equal): Likewise.
	* testsuite/20_util/allocator/requirements/typedefs.cc: Check
	that is_always_equal is not present in C++26.
	* testsuite/20_util/allocator/void.cc: Do not require
	is_always_equal for C++26.
	* testsuite/23_containers/vector/bool/cons/constexpr.cc: Add
	missing override of base's is_always_equal.
	* testsuite/23_containers/vector/cons/constexpr.cc: Likewise.