PR libstdc++/91807
* include/std/variant
(_Copy_assign_base::operator=(const _Copy_assign_base&):
Do the move-assignment from a temporary so that the temporary
is constructed with an explicit index.
* testsuite/20_util/variant/91807.cc: New.
These functions can't be noexcept because the iterators stored in the
sub_match objects can throw on any operation.
libstdc++-v3/ChangeLog:
PR libstdc++/94627
* include/bits/regex.h (operator==, operator!=): Remove noexcept
equality comparisons for match_results.
* testsuite/28_regex/match_results/94627.cc: New test.
The parser for binary numbers returned an error if the entire string
contains more digits than the result type. Leading zeros should be
ignored.
libstdc++-v3/ChangeLog:
* include/std/charconv (__from_chars_binary): Ignore leading zeros.
* testsuite/20_util/from_chars/1.cc: Check "0x1" for all bases,
not just 10 and 16.
* testsuite/20_util/from_chars/3.cc: New test.
The __detail::__to_chars_2 function assumes it won't be called with zero
values. However, when the output buffer is empty the caller doesn't
handle zero values correctly, and calls __to_chars_2 with a zero value,
resulting in an overflow of the empty buffer.
The __detail::__to_chars_i function should just return immediately for
an empty buffer, and otherwise ensure zero values are handled properly.
libstdc++-v3/ChangeLog:
PR libstdc++/95851
* include/std/charconv (__to_chars_i): Check for zero-sized
buffer unconditionally.
* testsuite/20_util/to_chars/95851.cc: New test.
G++ implements P1972R2 since r11-1597-0ca22d027ecc and so we no longer
need the P0608R3 special case to prevent narrowing conversions to bool.
Since non-GNU compilers don't necessarily implment P1972R2 yet, this
may cause a regression for those compilers. There is no feature-test
macro we can use to detect it though, so we'll have to live with it.
libstdc++-v3/ChangeLog:
PR libstdc++/95832
* include/std/variant (__detail::__variant::_Build_FUN): Remove
partial specialization to prevent narrowing conversions to bool.
* testsuite/20_util/variant/compile.cc: Test non-narrowing
conversions to bool.
* testsuite/20_util/variant/run.cc: Likewise.
A small tweak to the implementation of __includes, which in my
application saves 20% of the running time. I noticed it because using
range-v3 was giving unexpected performance gains.
Some of the gain comes from pulling the 2 calls ++__first1 out of the
condition so there is just one call. And most of the gain comes from
replacing the resulting
if (__comp(__first1, __first2))
;
else
++__first2;
with
if (!__comp(__first1, __first2))
++__first2;
I was very surprised that the code ended up being so different for such
a change, and I still don't really understand where the extra time is
going...
Anyway, while I blame the compiler for not generating very good code
with the current implementation, I believe the change can be seen as a
simplification.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (__includes): Simplify the code.
The attached patch changes the code generated for
std::optional<std::array<int,1024>>f(){return{};}
from
movq $0, (%rdi)
movq %rdi, %r8
leaq 8(%rdi), %rdi
xorl %eax, %eax
movq $0, 4084(%rdi)
movq %r8, %rcx
andq $-8, %rdi
subq %rdi, %rcx
addl $4100, %ecx
shrl $3, %ecx
rep stosq
movq %r8, %rax
or with different tuning
subq $8, %rsp
movl $4100, %edx
xorl %esi, %esi
call memset
addq $8, %rsp
to the much shorter
movb $0, 4096(%rdi)
movq %rdi, %rax
i.e. the same as the nullopt constructor.
The constructor was already non-trivial, so we don't lose that. It passes the
testsuite without regression, but there is no new testcase to verify the
better codegen.
libstdc++-v3/ChangeLog:
* include/std/optional (optional()): Explicitly define it.
The std::__uninitialized_default_n algorithm used by std::vector creates
an initial object as a local variable then copies that into the
destination range. If the object is too large for the stack this
crashes. We should create the first object directly into the
destination and then copy it from there.
This doesn't fix the bug for C++98, because in that case the initial
value is created as a default argument of the vector constructor i.e. in
the user's code, not inside libstdc++. We can't prevent that.
PR libstdc++/94540
* include/bits/stl_uninitialized.h (__uninitialized_default_1<true>):
Construct the first value at *__first instead of on the stack.
(__uninitialized_default_n_1<true>): Likewise.
Improve comments on several of the non-standard algorithms.
* testsuite/20_util/specialized_algorithms/uninitialized_default/94540.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_default_n/94540.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_value_construct/94540.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/94540.cc:
New test.
* testsuite/23_containers/vector/cons/94540.cc: New test.
The std::uninitialized_fill_n algorithm uses sd::fill_n for trivial
types, but that algorithm has a stronger requirement that the Size
parameter is convertible to an integral type. As the new test shows,
there are types which are valid for std::uninitialized_fill_n but which
produce a different result when converted to an integral type, or cannot
be converted at all. Only use the std::fill_n optimization when the Size
type is already an integral type.
The std::__uninitialized_default_n extension has the same problem, and
so does C++17's std::uninitialized_value_construct_n which uses it.
* include/bits/stl_uninitialized.h (uninitialized_fill_n): Only
use std::fill_n when the size is an integral type.
(__uninitialized_default_n): Likewise.
* testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill_n/sizes.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc:
New test.
This improves the previous fix for PR 95282, and extends it to also
apply to the exchange function (which has a similar problem and would
become ill-formed with my proposed fix for PR 95378).
PR libstdc++/95282
* include/bits/atomic_base.h (__atomic_impl::load): Use the _Val
alias instead of deducing _Tp as an unqualified type.
(__atomic_impl::exchange): Use the _Val alias to remove volatile
from the reinterpret_cast result type.
C++20 adds some new preconditions to std::atomic, which weren't
previously checked by our implementation.
* include/std/atomic (atomic): Add static assertions.
* testsuite/29_atomics/atomic/requirements/types_neg.cc: New test.
Although not required by SD-6 or the C++20 draft, we define the macro
__cpp_lib_constexpr_char_traits to indicate support for P0432R1. This
updates the value in C++20 mode for the P1032R1 changes to char_traits.
* include/bits/char_traits.h (__cpp_lib_constexpr_char_traits):
Update value for C++20.
* include/std/version (__cpp_lib_constexpr_char_traits): Likewise.
* testsuite/21_strings/char_traits/requirements/constexpr_functions_c++17.cc:
Update expected value.
* testsuite/21_strings/char_traits/requirements/constexpr_functions_c++20.cc:
Likewise.
Upon constexpr evaluation, char_traits move uses copy_backward, but its
last argument should be to the range end rather than its beginning.
2020-06-12 Paul Keir <paul.keir@uws.ac.uk>
* include/bits/char_traits.h (char_traits::move): constexpr move with
overlap was using copy_backward incorrectly.
* testsuite/21_strings/char_traits/requirements/constexpr_functions_c++20.cc:
New test.
Also fix the tests so they run without an explicit -std=gnu++2a in the
RUNTESTFLAGS, and test the new function on const-qualified objects.
* include/bits/atomic_base.h (atomic_flag::test): Add missing
const qualifiers.
* testsuite/29_atomics/atomic_flag/test/explicit.cc: Add
dg-options and verify results of test function.
* testsuite/29_atomics/atomic_flag/test/implicit.cc: Likewise.
The current code assumes that if the next character in the stream is
equal to the delimiter then we stopped because we saw that delimiter,
and so discards it. But in the testcase for the PR we stop because we
reached the maximum number of characters, and it's coincidence that the
next character equals the delimiter. We should not discard the next
character in that case.
The fix is to check that we haven't discarded __n characters already,
instead of checking whether the next character equals __delim. Because
we've already checked for EOF, if we haven't discarded __n yet then we
know we stopped because we saw the delimiter. On the other hand, if the
next character is the delimiter we don't know if that's why we stopped.
PR libstdc++/94749
* include/bits/istream.tcc (basic_istream::ignore(streamsize, CharT)):
Only discard an extra character if we didn't already reach the
maximum number.
* src/c++98/istream.cc (istream::ignore(streamsiz, char))
(wistream::ignore(streamsize, wchar_t)): Likewise.
* testsuite/27_io/basic_istream/ignore/char/94749.cc: New test.
* testsuite/27_io/basic_istream/ignore/wchar_t/94749.cc: New test.
ranges::copy and a number of other ranges algorithms have unwrapping
optimizations for iterators of type __normal_iterator, move_iterator and
reverse_iterator. But in the checks that guard these optimizations we
currently only test that the iterator of the iterator/sentinel pair has
the appropriate type before proceeding with the corresponding
optimization, and do not also test the sentinel type.
This breaks the testcase in this PR because this testcase constructs via
range adaptors a range whose begin() is a __normal_iterator and whose
end() is a custom sentinel type, and then performs ranges::copy on it.
From there we bogusly perform the __normal_iterator unwrapping
optimization on this iterator/sentinel pair, which immediately leads to
a constraint failure since the custom sentinel type does not model
sentinel_for<int*>.
This patch fixes this issue by refining each of the problematic checks
to also test that the iterator and sentinel types are the same before
applying the corresponding unwrapping optimization. Along the way, some
code simplifications are made.
libstdc++-v3/ChangeLog:
PR libstdc++/95578
* include/bits/ranges_algo.h (__lexicographical_compare_fn):
Also check that the iterator and sentinel have the same type before
applying the unwrapping optimization for __normal_iterator.
Split the check into two, one for the first iterator/sentinel
pair and another for second iterator/sentinel pair. Remove uses
of __niter_base, and remove uses of std::move on a
__normal_iterator.
* include/bits/ranges_algobase.h (__equal_fn): Likewise.
(__copy_or_move): Likewise. Perform similar adjustments for
the reverse_iterator and move_iterator optimizations. Inline
the checks into the if-constexprs, and use using-declarations to
make them less visually noisy. Remove uses of __niter_wrap.
(__copy_or_move_backward): Likewise.
* testsuite/25_algorithms/copy/95578.cc: New test.
* testsuite/25_algorithms/copy_backward/95578.cc: New test.
* testsuite/25_algorithms/equal/95578.cc: New test.
* testsuite/25_algorithms/lexicographical_compare/95578.cc: New test.
* testsuite/25_algorithms/move/95578.cc: New test.
* testsuite/25_algorithms/move_backward/95578.cc: New test.
Make the memcmp optimization work for std::deque iterators and safe
iterators.
Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
2020-06-08 François Dumont <fdumont@gcc.gnu.org>
Jonathan Wakely <jwakely@redhat.com>
* include/bits/deque.tcc (__lex_cmp_dit): New.
(__lexicographical_compare_aux1): Define overloads for deque
iterators.
* include/bits/stl_algobase.h (__lexicographical_compare::__3way):
New static member function.
(__lexicographical_compare<true>::__3way): Likewise.
(__lexicographical_compare<true>::__lc): Use __3way.
(__lexicographical_compare_aux): Rename to
__lexicographical_compare_aux1 and declare overloads for deque
iterators.
(__lexicographical_compare_aux): Define new forwarding function
that calls __lexicographical_compare_aux1 and declare new overloads
for safe iterators.
(lexicographical_compare): Do not use __niter_base on
parameters.
* include/debug/safe_iterator.tcc
(__lexicographical_compare_aux): Define overloads for safe
iterators.
* testsuite/25_algorithms/lexicographical_compare/1.cc: Add
checks with random access iterators.
* testsuite/25_algorithms/lexicographical_compare/deque_iterators/1.cc:
New test.
As clarified by LWG 3265, std::move_iterator is supposed to have an
assignment operator that converts from a different specialization of
std::move_iterator, which performs an assignment. That has always been
missing from libstdc++, so assigning a different type actually performs
a converting construction, then an assignment. This is non-conforming
for the (fairly contrived) case where the converting assignment is
well-formed but the converting construction is not.
* include/bits/stl_iterator.h (move_iterator::operator=): Define.
* testsuite/24_iterators/move_iterator/dr3265.cc: New test.
The standard requires that std::bad_optional_access' default
constructor has a non-throwing exception specification.
* include/std/optional (bad_optional_access): Define default
constructor and destructor as defaulted.
* testsuite/20_util/optional/bad_access.cc: New test.
With PR c++/92078 and PR c++/92103 both fixed, nested class templates
can now be constrained. That means a number of namespace-scope helpers
can be moved to the class scope, so they're only visible where they're
needed.
* include/bits/iterator_concepts.h (__detail::__ptr, __detail::__ref)
(__detail::__cat, __detail::__diff): Move to class scope in the
relevant __iterator_traits specializations.
(__iterator_traits<>): Use nested class templates instead of ones from
namespace __detail.
* include/bits/stl_iterator.h (__detail::__common_iter_ptr): Move to
class scope in iterator_traits<common_iterator<I, S>>.
(iterator_traits<common_iterator<I, S>>): Use nested class template
instead of __detail::__common_iter_ptr.
Since it was added in C++11, std::copy_n and std::ranges::copy_n should
do nothing given a negative size, but for random access iterators we add
the size to the iterator, possibly resulting in undefined behaviour.
Also, C++20 clarified that std::copy_n requires the Size type to be
convertible to an integral type. We previously assumed that it could be
directly used in arithmetic expressions, without conversion to an
integral type.
This also fixes a bug in the random_access_iterator_wrapper helper adds
some convenience aliases for using the iterator wrappers.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algobase.h (__copy_n_fn): Only call
ranges::copy for positive values.
* include/bits/stl_algo.h (copy_n): Convert Size argument to an
integral type and only call __copy_n for positive values.
* testsuite/util/testsuite_iterators.h
(random_access_iterator_wrapper::operator+=): Fix range check for
negative values.
(output_container, input_container, forward_container)
(bidirectional_container, random_access_container): New alias
templates.
* testsuite/25_algorithms/copy_n/5.cc: New test.
When given a type which can convert to any container-like type, the
C(const C&) copy constructor and C(const C::_Base&) converting
constructor are ambiguous. This change replaces the converting
constructor's parameter with a reference_wrapper-like type so that
calling that constructor requires an additional user-defined conversion.
This gives it a lower rank than the copy constructor, avoiding the
ambiguity.
While testing this change I discovered that __gnu_debug::forward_list
doesn't have a convering constructor from the std::forward_list base, so
this adds it.
We should probably consider whether the converting constructors should
be 'explicit' but I'm not changing that now.
libstdc++-v3/ChangeLog:
PR libstdc++/90102
* include/debug/deque (deque(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/forward_list (forward_list(_Base_ref)): New
constructor.
* include/debug/list (list(const _Base&)): Replace parameter
with a struct that wraps a const _Base&.
* include/debug/map.h (map(const _Base&)): Likewise.
* include/debug/multimap.h (multimap(const _Base&)): Likewise.
* include/debug/multiset.h (multiset(const _Base&)): Likewise.
* include/debug/set.h (set(const _Base&)): Likewise.
* include/debug/unordered_map (unordered_map(const _Base&))
(unordered_multimap(const _Base&)): Likewise.
* include/debug/unordered_set (unordered_set(const _Base&))
(unordered_multiset(const _Base&)): Likewise.
* testsuite/23_containers/vector/cons/destructible_debug_neg.cc:
Adjust dg-error line number.
* include/debug/vector (vector(const _Base&)): Likewise.
* testsuite/23_containers/deque/debug/90102.cc: New test.
* testsuite/23_containers/forward_list/debug/90102.cc: New test.
* testsuite/23_containers/list/debug/90102.cc: New test.
* testsuite/23_containers/map/debug/90102.cc: New test.
* testsuite/23_containers/multimap/debug/90102.cc: New test.
* testsuite/23_containers/multiset/debug/90102.cc: New test.
* testsuite/23_containers/set/debug/90102.cc: New test.
* testsuite/23_containers/unordered_map/debug/90102.cc: New test.
* testsuite/23_containers/unordered_multimap/debug/90102.cc: New test.
* testsuite/23_containers/unordered_multiset/debug/90102.cc: New test.
* testsuite/23_containers/unordered_set/debug/90102.cc: New test.
* testsuite/23_containers/vector/debug/90102.cc: New test.
When I refactored filesystem::path string conversions in
r11-587-584d52b088f9fcf78704b504c3f1f07e17c1cded I failed to update the
mingw-specific code in filesystem::u8path, causing a bootstrap failure.
This fixes it, and further refactors the mingw-specific code along the
same lines as the previous commit. All conversions from UTF-8 strings to
wide strings now use the same helper function, __wstr_from_utf8.
PR libstdc++/95392
* include/bits/fs_path.h (path::_S_to_string): Move to
namespace-scope and rename to ...
(__detail::__string_from_range): ... this.
[WINDOWS] (__detail::__wstr_from_utf8): New function template to
convert a char sequence containing UTF-8 to wstring.
(path::_S_convert(Iter, Iter)): Adjust call to _S_to_string.
(path::_S_convert_loc(Iter, Iter, const locale&)): Likewise.
(u8path(InputIterator, InputIterator)) [WINDOWS]: Use
__string_from_range to obtain a contiguous range and
__wstr_from_utf8 to obtain a wide string.
(u8path(const Source&)) [WINDOWS]: Use __effective_range to
obtain a contiguous range and __wstr_from_utf8 to obtain a wide
string.
(path::_S_convert(const _EcharT*, const _EcharT)) [WINDOWS]:
Use __wstr_from_utf8.
Those methods are making a double lookup in case of insertion, they can
perform only one.
PR libstdc++/95079
* include/bits/hashtable_policy.h (_Insert_base<>::try_emplace): New.
* include/bits/unordered_map.h (unordered_map<>::try_emplace): Adapt.
(unordered_map<>::insert_or_assign): Adapt.
PR libstdc++/95282
* include/bits/atomic_base.h (__atomic_impl::load): Add
cv-qualifiers to parameter so that _Tp is deduced as the
unqualified type.
* testsuite/29_atomics/atomic_float/95282.cc: New test.
The bug report is that transform_view's sentinel<false> cannot be
compared to its iterator<true>. The comparison is supposed to use
operator==(iterator<Const>, sentinel<Const>) after converting
sentinel<false> to sentinel<true>. However, the operator== is a hidden
friend so is not a candidate when comparing iterator<true> with
sentinel<false>. The required conversion would only happen if we'd found
the operator, but we can't find the operator until after the conversion
happens.
A new LWG issue has been reported, but not yet assigned a number. The
solution suggested by Casey Carter is to make the hidden friends of the
sentinel types work with iterators of any const-ness, so that no
conversions are required.
Patrick Palka observed that join_view has a similar problem and a
similar fix is used for its sentinel.
PR libstdc++/95322
* include/std/ranges (transform_view::_Sentinel): Allow hidden
friends to work with _Iterator<true> and _Iterator<false>.
(join_view::_Sentinel): Likewise.
* testsuite/std/ranges/adaptors/95322.cc: New test.
The std::reverse_iterator comparisons have always been implemented only
in terms of equality and less than. In C++98 that made no difference for
reasonable code, because when the underlying operators are the same type
they are required to support all comparisons anyway.
But since LWG 280 it's possible to compare reverse_iterator<X> and
reverse_iterator<Y>, and comparisons between X and Y might not support
the full set of equality and relational operators. This means that it
matters whether we implement operator!= as x.base() != y.base() or
!(x.base() == y.base()), and the current implementation is
non-conforming.
This was already fixed in GCC 10.1 for C++20, this change also fixes it
for all other -std modes.
PR libstdc++/94354
* include/bits/stl_iterator.h (reverse_iterator): Fix comparison
operators to use the correct operations on the underlying
iterators.
* testsuite/24_iterators/reverse_iterator/rel_ops.cc: New test.
This patch fixes the definition of common_iterator::operator-> when the
underlying iterator's operator* returns a non-reference.
The first problem is that the class __detail::_Common_iter_proxy is used
unqualified. Fixing that revealed another problem: the class's template
friend declaration of common_iterator doesn't match up with the
definition of common_iterator, because the friend declaration isn't
constrained.
If we try to make the friend declaration match up by adding constraints,
we run into frontend bug PR93467. So we currently can't correctly
express this friend relation between __detail::_Common_iter_proxy and
common_iterator.
As a workaround to this frontend bug, this patch moves the definition of
_Common_iter_proxy into the class template of common_iterator so that we
could instead express the friend relation via the injected-class-name.
(This bug was found when attempting to use views::common to work around
the compile failure with the testcase in PR95322.)
libstdc++-v3/ChangeLog:
PR libstdc++/95322
* include/bits/stl_iterator.h (__detail::_Common_iter_proxy):
Remove and instead define it ...
(common_iterator::_Proxy): ... here.
(common_iterator::operator->): Use it.
* testsuite/24_iterators/common_iterator/2.cc: New test.
* testsuite/std/ranges/adaptors/95322.cc: New test.
The body of this function isn't just a return statement, so it can't be
constexpr until C++14.
PR libstdc++/95289
* include/debug/helper_functions.h (__get_distance): Only declare
as a constexpr function for C++14 and up.
* testsuite/25_algorithms/copy/debug/95289.cc: New test.
This simplifies the logic of converting Source arguments and pairs of
InputIterator arguments into the native string format. For any input
that is a contiguous range of path::value_type (or char8_t for POSIX)
a string view can be created and the conversion can be done directly,
with no intermediate allocation. Previously some cases created a
basic_string unnecessarily, for example construction from a pair of
path::string_type::iterators, or a pair of non-const value_type*
pointers.
* include/bits/fs_path.h (__detail::_S_range_begin)
(__detail::_S_range_end, path::_S_string_from_iter): Replace with
overloaded function template __detail::__effective_range.
(__detail::__effective_range): New overloaded function template to
create a basic_string or basic_string_view for an effective range.
(__detail::__value_type_is_char): Use __detail::__effective_range.
Do not use remove_const on value type.
(__detail::__value_type_is_char_or_char8_t): Likewise.
(path::path(const Source&, format))
(path::path(const Source&, const locale&))
(path::operator/=(const Source&), path::append(const Source&))
(path::concat(const Source&)): Use __detail::__effective_range.
(path::_S_to_string(InputIterator, InputIterator)): New function
template to create a string view if possible, or string otherwise.
(path::_S_convert): Add overloads that convert a string returned
by __detail::__effective_range. Use if-constexpr to inline conversion
logic from all overloads of _Cvt::_S_convert.
(path::_S_convert_loc): Add overload that converts a string. Use
_S_to_string to avoid allocation when possible.
(path::_Cvt): Remove.
(path::operator+=(CharT)): Remove indirection through path::concat.
* include/experimental/bits/fs_path.h (path::_S_convert_loc): Add
overload for non-const pointers, to avoid constructing a std::string.
* src/c++17/fs_path.cc (path::_S_convert_loc): Replace conditional
compilation with call to _S_convert.
These functions were originally static members of the path class, but
the 'static' specifiers were not removed when they were moved to
namespace scope. This causes ODR violations when the functions are
called from functions defined in the header, which is incompatible with
Nathan's modules branch. Change them to 'inline' instead.
* include/bits/fs_path.h (__detail::_S_range_begin)
(__detail::_S_range_end): Remove unintentional static specifiers.
* include/experimental/bits/fs_path.h (__detail::_S_range_begin)
(__detail::_S_range_end): Likewise.
This replaces the filesystem::__detail::_Path SFINAE helper with two
separate helpers, _Path and _Path2. This avoids having one helper which
tries to check two different sets of requirements.
The _Path helper now uses variable templates instead of a set of
overloaded functions to detect specializations of basic_string or
basic_string_view.
The __not_<is_void<remove_pointer_t<_Tp1>> check is not necessary in
C++20 because iterator_traits<void*> is now empty. For C++17 replace
that check with a __safe_iterator_traits helper with partial
specializations for void pointers.
Finally, the __is_encoded_char check no longer uses remove_const_t,
which means that iterators with a const value_type will no longer be
accepted as arguments for path creation. Such iterators resulted in
undefined behaviour anyway, so it's still conforming to reject them in
the constraint checks.
* include/bits/fs_path.h (filesystem::__detail::__is_encoded_char):
Replace alias template with variable template. Don't remove const.
(filesystem::__detail::__is_path_src): Replace overloaded function
template with variable template and specializations.
(filesystem::__detail::__is_path_iter_src): Replace alias template
with class template.
(filesystem::__detail::_Path): Use __is_path_src. Remove support for
iterator pairs.
(filesystem::__detail::_Path2): New alias template for checking
InputIterator requirements.
(filesystem::__detail::__constructible_from): Remove.
(filesystem::path): Replace _Path<Iter, Iter> with _Path2<Iter>.
* testsuite/27_io/filesystem/path/construct/80762.cc: Check with two
constructor arguments of void and void* types.
Checking whether a filesystem::path constructor argument is an iterator
requires instantiating std::iterator_traits. In C++20 that checks for
satisfaction of std::iterator_traits constraints, which checks if the
type is copyable, which can end up recursing back to the path
constructor. The fix in LWG 3420 is to reorder the cpp17-iterator
concept's constraints to check if the type looks vaguely like an
iterator before checking copyable. That avoids the recursion for types
which definitely aren't iterators, but isn't foolproof.
PR libstdc++/93983
* include/bits/iterator_concepts.h (__detail::__cpp17_iterator):
Reorder constraints to avoid recursion when constructors use
iterator_traits (LWG 3420).
* testsuite/24_iterators/customization_points/lwg3420.cc: New test.
Vxworks 7's malloc, like Solaris', only ensures 8-byte alignment of
returned pointers on 32-bit x86, though GCC's stddef.h defines
max_align_t with 16-byte alignment for __float128. This patch enables
on x86-vxworks the same memory_resource workaround used for x86-solaris.
The testsuite also had a workaround, defining BAD_MAX_ALIGN_T and
xfailing the test; extend those to x86-vxworks as well, and remove the
check for char-aligned requested allocation to be aligned like
max_align_t. With that change, the test passes on x86-vxworks; I'm
guessing that's the same reason for the test not to pass on
x86-solaris (and on x86_64-solaris -m32), so with the fix, I'm
tentatively removing the xfail.
for libstdc++-v3/ChangeLog
PR libstdc++/77691
* include/experimental/memory_resource
(__resource_adaptor_imp::do_allocate): Handle max_align_t on
x86-vxworks as on x86-solaris.
(__resource_adaptor_imp::do_deallocate): Likewise.
* testsuite/experimental/memory_resource/new_delete_resource.cc:
Drop xfail.
(BAD_MAX_ALIGN_T): Define on x86-vxworks as on x86-solaris.
(test03): Drop max-align test for char-aligned alloc.
* include/bits/atomic_base.h (atomic_flag): Implement test member
function.
* include/std/version: Define __cpp_lib_atomic_flag_test.
* testsuite/29_atomics/atomic_flag/test/explicit.cc: New file.
* testsuite/29_atomics/atomic_flag/test/implicit.cc: New file.
Some new algorithms need to use _GLIBCXX_STD_A to refer to the "normal"
version of the algorithm, to workaround the namespace dance done for
parallel mode.
PR libstdc++/94971 (partial)
* include/bits/ranges_algo.h (ranges::__sample_fn): Qualify
std::sample using macro to work in parallel mode.
(__sort_fn): Likewise for std::sort.
(ranges::__nth_element_fn): Likewise for std::nth_element.
* include/bits/stl_algobase.h (lexicographical_compare_three_way):
Likewise for std::__min_cmp.
* include/parallel/algobase.h (lexicographical_compare_three_way):
Add to namespace std::__parallel.
