Tim Song pointed out that using __underlying_type is ill-formed for
incomplete enumeration types, and is_scoped_enum doesn't require a
complete type. This changes the trait to check for conversion to int
instead of to the underlying type.
In order to give the correct result when the trait is used in the
enumerator-list of an incomplete type the partial specialization for
enums has an additional check that fails for incomplete types. This
assumes that an incompelte enumeration type must be an unscoped
enumeration, and so the primary template (with a std::false_type base
characteristic) can be used. This isn't necessarily true, but it is not
currently possible to refer to a scoped enumeration type before its type
is complete (PR c++/89025).
It should be possible to use requires(remove_cv_t<_Tp> __t) in the
partial specialization's assignablility check, but that currently gives
an ICE (PR c++/99968) so there is an extra partial specialization of
is_scoped_enum<const _Tp> to handle const types.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_scoped_enum<T>): Constrain partial
specialization to not match incomplete enum types. Use a
requires-expression instead of instantiating is_convertible.
(is_scoped_enum<const T>): Add as workaround for PR c++/99968.
* testsuite/20_util/is_scoped_enum/value.cc: Check with
incomplete types and opaque-enum-declarations.
Add [[nodiscard]] to functions that are effectively just a static_cast,
as per P2351. Also add it to std::addressof.
libstdc++-v3/ChangeLog:
* include/bits/move.h (forward, move, move_if_noexcept)
(addressof): Add _GLIBCXX_NODISCARD.
* include/bits/ranges_cmp.h (identity::operator()): Add
nodiscard attribute.
* include/c_global/cstddef (to_integer): Likewise.
* include/std/bit (bit_cast): Likewise.
* include/std/utility (as_const, to_underlying): Likewise.
libstdc++-v3/ChangeLog:
* include/bits/move.h (forward): Change static_assert message
to be unambiguous about what must be true.
* testsuite/20_util/forward/c_neg.cc: Adjust dg-error.
* testsuite/20_util/forward/f_neg.cc: Likewise.
libstdc++-v3/ChangeLog:
* include/bits/alloc_traits.h: Use markdown for code font.
* include/bits/basic_string.h: Fix @param names.
* include/bits/max_size_type.h: Remove period after @file.
* include/bits/regex.h: Fix duplicate @retval names, and rename.
* include/ext/pb_ds/detail/priority_queue_base_dispatch.hpp: Add
group open to match existing group close.
* include/ext/pb_ds/priority_queue.hpp: Add blank line before group
open.
std::ranges::reverse_view uses make_reverse_iterator in its
implementation as described in [range.reverse.view]. This accidentally
allows ADL as an unqualified name is used in the call. According to
[contents], however, this should be treated as a qualified lookup into
the std namespace.
This leads to errors due to ambiguous name lookups when another
make_reverse_iterator function is found via ADL.
libstdc++-v3/Changelog:
* include/std/ranges (reverse_view::begin, reverse_view::end):
Qualify make_reverse_iterator calls to avoid ADL.
* testsuite/std/ranges/adaptors/reverse.cc: Test that
views::reverse works when make_reverse_iterator is defined
in an associated namespace.
Clang does not currently support the __ibm128 type [1] and only supports
the __ieee128 type in the unreleased 12.0.0 version [2]. That means it
is not possible to provide support for -mabi=ieeelongdouble with Clang
in an ABI compatible way (as we do for GCC by defining new facets and
other types in the __gnu_cxx_ldbl128 namespace).
By preventing the definition of _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT when
compiling with Clang, all uses of __ibm128 and __ieee128 types will be
disabled. This can be revisited in future when Clang supports the types
(and provides a way to detect that support using the preprocessor).
[1] https://reviews.llvm.org/D93377
[2] https://reviews.llvm.org/D97846
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT):
Do not define when compiling with Clang.
This implements the new string_view constructor proposed by P1989R2.
This hasn't been voted into the C++23 draft yet, but it's been reviewed
by LWG and is expected to be approved at the next WG21 meeting.
libstdc++-v3/ChangeLog:
* include/std/string_view (basic_string_view(Range&&)): Define new
constructor and deduction guide.
* testsuite/21_strings/basic_string_view/cons/char/range_c++20.cc: New test.
* testsuite/21_strings/basic_string_view/cons/wchar_t/range_c++20.cc: New test.
This implements the proposed changes for LWG 3537 (which we're allowed
to do as an extension whatever the outcome of the issue). I noticed we
didn't implement LWG 2280 completely, as the std::begin and std::end
overloads for arrays were not noexcept.
libstdc++-v3/ChangeLog:
* include/bits/range_access.h (begin(T (&)[N]), end(T (&)[N])):
Add missing 'noexcept' as per LWG 2280.
(rbegin(T (&)[N]), rend(T (&)[N]), rbegin(initializer_list<T>))
(rend(initializer_list<T>)): Add 'noexcept' as per LWG 3537.
* testsuite/24_iterators/range_access/range_access.cc: Check for
expected noexcept specifiers. Check result types of generic
std::begin and std::end overloads.
* testsuite/24_iterators/range_access/range_access_cpp14.cc:
Check for expected noexcept specifiers.
* testsuite/24_iterators/range_access/range_access_cpp17.cc:
Likewise.
Implement this C++23 feature, as proposed by P1048R1.
This implementation assumes that a C++23 compiler supports concepts
already. I don't see any point in using preprocessor hacks to detect
compilers which define __cplusplus to a post-C++20 value but don't
support concepts yet.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_scoped_enum): Define.
* include/std/version (__cpp_lib_is_scoped_enum): Define.
* testsuite/20_util/is_scoped_enum/value.cc: New test.
* testsuite/20_util/is_scoped_enum/version.cc: New test.
The new std::call_once implementation is not backwards compatible,
contrary to my intention. Because std::once_flag::_M_active() doesn't
write glibc's "fork generation" into the pthread_once_t object, it's
possible for glibc and libstdc++ to run two active executions
concurrently. This violates the primary invariant of the feature!
This patch reverts std::once_flag and std::call_once to the old
implementation that uses pthread_once. This means PR 66146 is a problem
again, but glibc has been changed to solve that. A new API similar to
pthread_once but supporting failure and resetting the pthread_once_t
will be proposed for inclusion in glibc and other C libraries.
This change doesn't simply revert r11-4691 because I want to retain the
new implementation for non-ghtreads targets (which didn't previously
support std::call_once at all, so there's no backwards compatibility
concern). This also leaves the new std::call_once::_M_activate() and
std::call_once::_M_finish(bool) symbols present in libstdc++.so.6 so
that code already compiled against GCC 11 can still use them. Those
symbols will be removed in a subsequent commit (which distros can choose
to temporarily revert if needed).
libstdc++-v3/ChangeLog:
PR libstdc++/99341
* include/std/mutex [_GLIBCXX_HAVE_LINUX_FUTEX] (once_flag):
Revert to pthread_once_t implementation.
[_GLIBCXX_HAVE_LINUX_FUTEX] (call_once): Likewise.
* src/c++11/mutex.cc [_GLIBCXX_HAVE_LINUX_FUTEX]
(struct __once_flag_compat): New type matching the reverted
implementation of once_flag using futexes.
(once_flag::_M_activate): Remove, replace with ...
(_ZNSt9once_flag11_M_activateEv): ... alias symbol.
(once_flag::_M_finish): Remove, replace with ...
(_ZNSt9once_flag9_M_finishEb): ... alias symbol.
* testsuite/30_threads/call_once/66146.cc: Removed.
This implements operator++, operator-- and operator<=> for the
integer-class types defined in max_size_type.h, which I overlooked
when originally implementing the class.
libstdc++-v3/ChangeLog:
* include/bits/max_size_type.h (__max_size_type::operator _Tp):
Fix formatting.
(__max_size_type::operator++): Define.
(__max_size_type::operator--): Likewise.
(__max_size_type::operator<=>): Conditionally define (in place
of the other comparison operators).
(__max_diff_type::operator _Tp): Fix formatting.
(__max_diff_type::operator++): Define.
(__max_diff_type::operator--): Likewise.
(__max_diff_type::operator<=>): Conditionally define (in place
of the other comparison operators).
* testsuite/std/ranges/iota/max_size_type.cc (test01): Test
these operator overloads.
The standard only specifies that barrier::arrival_token is a move
constructible and move assignable type. We originally used a scoped enum
type, but that means we do not diagnose non-portable code that makes
copies of arrival tokens (or compares them for equality, or uses them as
keys in map!) This wraps the enum in a move-only class type, so that
users are forced to pass it correctly.
The move constructor and move assignment operator of the new class do
not zero out the moved-from token, as that would add additional
instructions. That means that passing a moved-from token will work with
our implementation, despite being a bug in the user code. We could
consider doing that zeroing out in debug mode.
libstdc++-v3/ChangeLog:
* include/std/barrier (barrier::arrival_token): New move-only
class that encapsulates the underlying token value.
As Lewis Baker wrote in the PR:
> The 'fetch_sub()' operation in _M_release_ownership() should be using
> memory_order::acq_rel instead of memory_order::release. The use of
> 'release' only is insufficient as it does not synchronise with any
> corresponding 'acquire' operation.
> With the current implementation, it's possible that a prior write to
> one of the _M_value or _M_head data-members by a thread releasing the
> second-to-last reference might not be visible to another thread that
> releases the last reference and frees the memory, resulting in
> potential write to freed memory.
This simply changes the memory order to acq_rel as suggested.
libstdc++-v3/ChangeLog:
PR libstdc++/99537
* include/std/stop_token (_Stop_state_t::_M_release_ownership):
Use acq_rel memory ordering.
This avoids a false positive -Wmaybe-uninitialized warning, by
initializing _M_saved on construction.
libstdc++-v3/ChangeLog:
PR libstdc++/99536
* include/bits/random.h (normal_distribution): Use
default-initializer for _M_saved and _M_saved_available.
This adds missing includes to internal library headers which get
included from more than one other header, so that they can be compiled
as a stand-alone header unit.
For existing use cases these includes are no-ops because they're already
done by the header that includes these files. For compiling them as a
header unit, this ensures that they include what they use.
libstdc++-v3/ChangeLog:
PR libstdc++/99413
* include/bits/align.h: Include debug/assertions.h.
* include/bits/codecvt.h: Include bits/c++config.h.
* include/bits/enable_special_members.h: Likewise.
* include/bits/erase_if.h: Likewise.
* include/bits/functional_hash.h: Include <type_traits>.
* include/bits/invoke.h: Include bits/move.h.
* include/bits/ostream_insert.h: Include bits/exception_defines.h.
* include/bits/parse_numbers.h: Include <type_traits>.
* include/bits/predefined_ops.h: Include bits/c++config.h.
* include/bits/range_access.h: Include bits/stl_iterator.h.
* include/bits/stl_bvector.h: Do not include bits/stl_vector.h.
* include/bits/stl_iterator.h: Include bits/stl_iterator_base_types.h.
* include/bits/stl_uninitialized.h: Include bits/stl_algobase.h.
* include/bits/uniform_int_dist.h: Include bits/concept_check.h.
* include/bits/unique_lock.h: Include bits/std_mutex.h.
* include/debug/assertions.h: Include bits/c++config.h.
The proposed resolution for this library issue simplifies the
constraints for compare_three_way, ranges::equal_to, ranges::less etc.
so that they do not work with types which are convertible to pointers
but which fail to meet the usual syntactic requirements for the
comparisons.
This affects the example in PR libstdc++/93628 but doesn't fix the
problem described in that report.
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__eq_builtin_ptr_cmp): Remove.
(ranges::equal_to, ranges::not_equal_to): Do not constrain
with __eq_builtin_ptr_cmp.
(ranges::less, ranges::greater, ranges::less_equal)
(ranges::greater_equal): Do not constrain with
__less_builtin_ptr_cmp.
* libsupc++/compare (compare_three_way): Do not constrain with
__3way_builtin_ptr_cmp.
* testsuite/18_support/comparisons/object/builtin-ptr-three-way.cc: Moved to...
* testsuite/18_support/comparisons/object/lwg3530.cc: ...here.
* testsuite/20_util/function_objects/range.cmp/lwg3530.cc: New test.
As can be seen on:
unsigned char f1 (unsigned char x, int y) { return std::rotl (x, y); }
unsigned char f2 (unsigned char x, int y) { return std::rotr (x, y); }
unsigned short f3 (unsigned short x, int y) { return std::rotl (x, y); }
unsigned short f4 (unsigned short x, int y) { return std::rotr (x, y); }
unsigned int f5 (unsigned int x, int y) { return std::rotl (x, y); }
unsigned int f6 (unsigned int x, int y) { return std::rotr (x, y); }
unsigned long int f7 (unsigned long int x, int y) { return std::rotl (x, y); }
unsigned long int f8 (unsigned long int x, int y) { return std::rotr (x, y); }
unsigned long long int f9 (unsigned long long int x, int y) { return std::rotl (x, y); }
unsigned long long int f10 (unsigned long long int x, int y) { return std::rotr (x, y); }
//unsigned __int128 f11 (unsigned __int128 x, int y) { return std::rotl (x, y); }
//unsigned __int128 f12 (unsigned __int128 x, int y) { return std::rotr (x, y); }
constexpr auto a = std::rotl (1234U, 0);
constexpr auto b = std::rotl (1234U, 5);
constexpr auto c = std::rotl (1234U, -5);
constexpr auto d = std::rotl (1234U, -__INT_MAX__ - 1);
the current <bit> definitions of std::__rot[lr] aren't pattern recognized
as rotates, they are too long/complex for that, starting with signed modulo,
special case for 0 and different cases for positive and negative.
For types with power of two bits the following patch adds definitions that
the compiler can pattern recognize and turn e.g. on x86_64 into ro[lr][bwlq]
instructions. For weirdo types like unsigned __int20 etc. it keeps the
current definitions.
2021-03-06 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/99396
* include/std/bit (__rotl, __rotr): Add optimized variants for power of
two _Nd which the compiler can pattern match the rotates.
Two simd tests FAIL on Solaris, both SPARC and x86:
FAIL: experimental/simd/standard_abi_usable.cc -msse2 -O2 -Wno-psabi (test for excess errors)
FAIL: experimental/simd/standard_abi_usable_2.cc -msse2 -O2 -Wno-psabi (test for excess errors)
This happens because the simd headers use identifiers documented in the
libstdc++ manual as reserved by system headers.
Fixed as follows, tested on i386-pc-solaris2.11, sparc-sun-solaris2.11,
and x86_64-pc-linux-gnu.
2021-02-01 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libstdc++-v3:
* include/experimental/bits/simd.h: Replace reserved _X, _B by
_Xp, _Bp.
* include/experimental/bits/simd_builtin.h: Likewise.
* include/experimental/bits/simd_x86.h: Likewise.
The conversions to integer types are explicit, so need to use the
correct type. Converting to uint32_t only works if that is the same type
as unsigned.
libstdc++-v3/ChangeLog:
PR libstdc++/99301
* include/std/chrono (year_month_day::_M_days_since_epoch()):
Convert chrono::month and chrono::day to unsigned before
converting to uint32_t.
Implement P1682R2 as just approved for C++23.
libstdc++-v3/ChangeLog:
* include/std/utility (to_underlying): Define.
* include/std/version (__cpp_lib_to_underlying): Define.
* testsuite/20_util/to_underlying/1.cc: New test.
* testsuite/20_util/to_underlying/version.cc: New test.
This patch reimplements std::chrono::year_month_day_last:day() which yields the
last day of a particular month. The current implementation uses a look-up table
implemented as an unsigned[12] array. The new implementation instead
is based on
the fact that a month m in [1, 12], except for m == 2 (February), is
either 31 or
30 days long and m's length depends on two things: m's parity and whether m >= 8
or not. These two conditions are determined by the 0th and 3th bit of m and,
therefore, cheap and straightforward bit-twiddling can provide the right result.
Measurements in x86_64 [1] suggest a 10% performance boost. Although this does
not seem to be huge, notice that measurements are done in hot L1 cache
conditions which might not be very representative of production runs. Also
freeing L1 cache from holding the look-up table might allow performance
improvements elsewhere.
References:
[1] https://github.com/cassioneri/calendar
libstdc++-v3/ChangeLog:
* include/std/chrono (year_month_day_last:day): New
implementation.
This patch reimplements std::chrono::year::is_leap(). Leap year check is
ubiquitously implemented (including here) as:
y % 4 == 0 && (y % 100 != 0 || y % 400 == 0).
The rationale being that testing divisibility by 4 first implies an earlier
return for 75% of the cases, therefore, avoiding the needless calculations of
y % 100 and y % 400. Although this fact is true, it does not take into account
the cost of branching. This patch, instead, tests divisibility by 100 first:
(y % 100 != 0 || y % 400 == 0) && y % 4 == 0.
It is certainly counterintuitive that this could be more efficient since among
the three divisibility tests (4, 100 and 400) the one by 100 is the only one
that can never provide a definitive answer and a second divisibility test (by 4
or 400) is always required. However, measurements [1] in x86_64 suggest this is
3x more efficient! A possible explanation is that checking divisibility by 100
first implies a split in the execution path with probabilities of (1%, 99%)
rather than (25%, 75%) when divisibility by 4 is checked first. This decreases
the entropy of the branching distribution which seems to help prediction.
Given that y belongs to [-32767, 32767] [time.cal.year.members], a more
efficient algorithm [2] to check divisibility by 100 is used (instead of
y % 100 != 0). Measurements suggest that this optimization improves performance
by 20%.
The patch adds a test that exhaustively compares the result of this
implementation with the ubiquitous one for all y in [-32767, 32767]. Although
its completeness, the test completes in a matter of seconds.
References:
[1] https://stackoverflow.com/a/60646967/1137388
[2] https://accu.org/journals/overload/28/155/overload155.pdf#page=16
libstdc++-v3/ChangeLog:
* include/std/chrono (year::is_leap): New implementation.
* testsuite/std/time/year/2.cc: New test.
This patch reimplements std::chrono::year_month_day::_M_days_since_epoch()
which calculates the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.2 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
https://arxiv.org/abs/2102.06959.
The aforementioned paper benchmarks the implementation against several
counterparts, including libc++'s (which is identical to the current
implementation). The results, shown in Figure 3, indicate the new algorithm is
1.7 times faster than the current one.
The patch adds a test which loops through all dates in [-32767/01/01,
32767/12/31], and for each of them, gets the number of days and compares the
result against its expected value. The latter is calculated using a much
simpler and easy to understand algorithm but which is also much slower.
The dates used in the test covers the full range of possible values
[time.cal.year.members]. Despite its completeness the test runs in matter of
seconds.
libstdc++-v3/ChangeLog:
* include/std/chrono (year_month_day::_M_days_since_epoch):
New implementation.
* testsuite/std/time/year_month_day/4.cc: New test.
This patch reimplements std::chrono::year_month_day::_S_from_days() which
retrieves a date from the number of elapsed days since 1970/01/01. The new
implementation is based on Proposition 6.3 of Neri and Schneider, "Euclidean
Affine Functions and Applications to Calendar Algorithms" available at
https://arxiv.org/abs/2102.06959.
The aforementioned paper benchmarks the implementation against several
counterparts, including libc++'s (which is identical to the current
implementation). The results, shown in Figure 4, indicate the new algorithm is
2.2 times faster than the current one.
The patch adds a test which loops through all integers in [-12687428, 11248737],
and for each of them, gets the corresponding date and compares the result
against its expected value. The latter is calculated using a much simpler and
easy to understand algorithm but which is also much slower.
The interval used in the test covers the full range of values for which a
roundtrip must work [time.cal.ymd.members]. Despite its completeness the test
runs in a matter of seconds.
libstdc++-v3/ChangeLog:
* include/std/chrono (year_month_day::_S_from_days): New
implementation.
* testsuite/std/time/year_month_day/3.cc: New test.
Because of LWG 467, std::char_traits<char>::lt compares the values
cast to unsigned char rather than char, so even when char is signed
we get unsigned comparision. std::char_traits<char>::compare uses
__builtin_memcmp and that works the same, but during constexpr evaluation
we were calling __gnu_cxx::char_traits<char_type>::compare. As
char_traits::lt is not virtual, __gnu_cxx::char_traits<char_type>::compare
used __gnu_cxx::char_traits<char_type>::lt rather than
std::char_traits<char>::lt and thus compared chars as signed if char is
signed.
This change fixes it by inlining __gnu_cxx::char_traits<char_type>::compare
into std::char_traits<char>::compare by hand, so that it calls the right
lt method.
2021-02-23 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/99181
* include/bits/char_traits.h (char_traits<char>::compare): For
constexpr evaluation don't call
__gnu_cxx::char_traits<char_type>::compare but do the comparison loop
directly.
* testsuite/21_strings/char_traits/requirements/char/99181.cc: New
test.
In GCC 10, parallel_backend.h just included parallel_backend_{serial,tbb}.h and
did nothing beyond that, and parallel_backend_tbb.h provided directly
namespace __pstl { namespace __par_backend { ... } }
and defined everything in there, while parallel_backend_serial.h did:
namespace __pstl { namespace __serial { ... } } and had this
namespace __pstl { namespace __par_backend { using namespace __pstl::__serial; } }
at the end.
In GCC 11, parallel_backend.h does:
namespace __pstl { namespace __par_backend = __serial_backend; }
after including parallel_backend_serial.h or
namespace __pstl { namespace __par_backend = __tbb_backend; }
after including parallel_backend_tbb.h. The latter then has:
namespace __pstl { namespace __tbb_backend { ... } }
and no using etc. at the end, while parallel_backend_serial.h changed to:
namespace __pstl { namespace __serial_backend { ... } }
but has this leftover block from the GCC 10 times. Even changing that
using namespace __pstl::__serial;
to
using namespace __pstl::__serial_backend;
doesn't work, as it clashes with
namespace __pstl { namespace __par_backend = __serial_backend; }
in parallel_backend.h.
2021-02-23 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/97549
* include/pstl/parallel_backend_serial.h: Remove __pstl::__par_backend.
My recent change to the preprocessor conditions in __thread_relax() was
supposed to also change the __gthread_yield() call to __thread_yield(),
which has the right preprocessor checks. Instead I just removed the
check for _GLIBCXX_USE_SCHED_YIELD which means the __gthread_yield()
call will be ill-formed for non-gthreads targets, and targets without
sched_yield(). This fixes it properly.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__thread_relax()): Call
__thread_yield() not __gthread_yield().
The __gthread_yield() function is only defined for gthreads targets, so
check _GLIBCXX_HAS_GTHREADS before using it.
Also reorder __thread_relax and __thread_yield so that the former can
use the latter instead of repeating the same preprocessor checks.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__thread_yield()): Check
_GLIBCXX_HAS_GTHREADS before using __gthread_yield.
(__thread_relax()): Use __thread_yield() instead of repeating
the preprocessor checks for __gthread_yield.
The once_flag::_M_activate() function is only ever called immediately
after a call to once_flag::_M_passive(), and so in the non-gthreads case
it is impossible for _M_passive() to be true in the body of
_M_activate(). Add a check for it anyway, to avoid warnings about
missing return.
Also replace a non-reserved name with a reserved one.
libstdc++-v3/ChangeLog:
* include/std/mutex (once_flag::_M_activate()): Add explicit
return statement for passive case.
(once_flag::_M_finish(bool)): Use reserved name for parameter.
libstdc++-v3/ChangeLog:
* include/experimental/internet (address_v6::to_string): Include
scope ID in string.
* testsuite/experimental/net/internet/address/v6/members.cc:
Test to_string() results.
This avoids some warnings when building with -fno-rtti because the
function parameters are only used when RTTI is enabled.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_base.h (__shared_ptr::_M_get_deleter):
Add unused attribute to parameter.
* src/c++11/shared_ptr.cc (_Sp_make_shared_tag::_S_eq):
Likewise.
Add unordered containers heterogeneous lookup member functions find, count, contains and
equal_range in C++20. Those members are considered for overload resolution only if hash and
equal functors used to instantiate the container have a nested is_transparent type.
libstdc++-v3/ChangeLog:
* include/bits/stl_tree.h
(__has_is_transparent, __has_is_transparent_t): Move...
* include/bits/stl_function.h: ...here.
* include/bits/hashtable_policy.h (_Hash_code_base<>::_M_hash_code_tr): New..
(_Hashtable_base<>::_M_equals_tr): New.
* include/bits/hashtable.h (_Hashtable<>::_M_find_tr, _Hashtable<>::_M_count_tr,
_Hashtable<>::_M_equal_range_tr): New member function templates to perform
heterogeneous lookup.
(_Hashtable<>::_M_find_before_node_tr): New.
(_Hashtable<>::_M_find_node_tr): New.
* include/bits/unordered_map.h (unordered_map::find<>, unordered_map::count<>,
unordered_map::contains<>, unordered_map::equal_range<>): New member function
templates to perform heterogeneous lookup.
(unordered_multimap::find<>, unordered_multimap::count<>,
unordered_multimap::contains<>, unordered_multimap::equal_range<>): Likewise.
* include/bits/unordered_set.h (unordered_set::find<>, unordered_set::count<>,
unordered_set::contains<>, unordered_set::equal_range<>): Likewise.
(unordered_multiset::find<>, unordered_multiset::count<>,
unordered_multiset::contains<>, unordered_multiset::equal_range<>): Likewise.
* include/debug/unordered_map
(unordered_map::find<>, unordered_map::equal_range<>): Likewise.
(unordered_multimap::find<>, unordered_multimap::equal_range<>): Likewise.
* include/debug/unordered_set
(unordered_set::find<>, unordered_set::equal_range<>): Likewise.
(unordered_multiset::find<>, unordered_multiset::equal_range<>): Likewise.
* testsuite/23_containers/unordered_map/operations/1.cc: New test.
* testsuite/23_containers/unordered_multimap/operations/1.cc: New test.
* testsuite/23_containers/unordered_multiset/operations/1.cc: New test.
* testsuite/23_containers/unordered_set/operations/1.cc: New test.
The coroutine_handle<void>::from_address(void*) version is already
noexcept, and they do the same thing. Make them consistent.
libstdc++-v3/ChangeLog:
PR libstdc++/99021
* include/std/coroutine (coroutine_handle<P>::from_address): Add
noexcept.
The patch fixes build issues occurring if build parameter
"--enable-cstdio=stdio_pure" is specified and no unistd.h is
present in the environment.
libstdc++-v3/ChangeLog:
* include/ext/stdio_sync_filebuf.h: Remove unused <unistd.h>.
* src/c++17/fs_ops.cc (fs::permissions): Qualify mode_t.
In the PR there are several possibilities how to improve _M_disjunct at
least in certain cases so that the compiler can figure out at least in some
cases where __s is provably disjunct from _M_data() ... _M_data() + this->size()
but it is probably GCC 12 material.
The false positive warning is on this particular copy, which is done for
non-disjunct pointers when __len2 > __len1 and the __s >= __p + __len1,
i.e. __s used to point to the characters moved through _S_move a few lines earlier
by __len2 - __len1 characters up to make space. That is why the
_S_copy source is __s + __len2 - __len1. Unfortunately, when the compiler
can't prove objects are disjunct, that copying from __s + __len2 - __len1
of __len2 characters can very well mean accessing characters the source
object (if it is not disjunct) provably can't have.
The following patch works around that by making the _S_copy be a __p based
pointer instead of __s based pointer.
__s + __len2 - __len1
and
__p + (__s - __p) + (__len2 - __len1)
have the same value and the latter may seem to be uselessly longer,
but it seems at least currently in GIMPLE we keep it that way and so that is
what the warning code during expansion will see, and only actually
optimize it to __s + __len2 - __len1 during RTL when we lose information
on what is a pointer and what is a mere offset with the same mode.
So, in the end we emit exactly the same assembly, just without the false
positive warning.
2021-02-09 Jakub Jelinek <jakub@redhat.com>
PR middle-end/98465
* include/bits/basic_string.tcc (basic_string::_M_replace): When __s
points to the characters moved by earlier _S_move, compute the source
address using expression based on the __p pointer rather than __s
pointer.
* g++.dg/warn/Wstringop-overread-1.C: New test.
The find_first_set and find_last_set method is not optimal for neon, it
needs to be improved by synthesized with horizontal adds(vaddv) which
will reduce the generated assembly code. In the following cases,
vaddvq_s16 will generate 2 instructions but vpadd_s16 will generate 4
instructions:
# vaddvq_s16
vaddvq_s16(__asint);
// addv h0, v1.8h
// smov w1, v0.h[0]
# vpadd_s16
vpaddq_s16(vpaddq_s16(vpaddq_s16(__asint, __zero), __zero), __zero)[0]
// addp v1.8h,v1.8h,v2.8h
// addp v1.8h,v1.8h,v2.8h
// addp v1.8h,v1.8h,v2.8h
// smov w1, v1.h[0]
#
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd_neon.h: Replace repeated vpadd
calls with a single vaddv for aarch64.
From 9.7.4 in Parallelism TS 2. For some reason I overlooked these two
functions. Implement them via call to _S_reduce.
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h: Add __detail::_Minimum and
__detail::_Maximum to use them as _BinaryOperation to _S_reduce.
Add hmin and hmax overloads for simd and const_where_expression.
* include/experimental/bits/simd_scalar.h
(_SimdImplScalar::_S_reduce): Make unused _BinaryOperation
parameter const-ref to allow calling _S_reduce with an rvalue.
* testsuite/experimental/simd/tests/reductions.cc: Add tests for
hmin and hmax. Since the compiler statically determined that all
tests pass, repeat the test after a call to make_value_unknown.
POWER7 does not support __vector long long reductions, making the
generic _S_popcount implementation ill-formed. Specializing _S_popcount
for PPC allows optimization and avoids the issue.
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h: Add __have_power10vec
conditional on _ARCH_PWR10.
* include/experimental/bits/simd_builtin.h: Forward declare
_MaskImplPpc and use it as _MaskImpl when __ALTIVEC__ is
defined.
(_MaskImplBuiltin::_S_some_of): Call _S_popcount from the
_SuperImpl for optimizations and correctness.
* include/experimental/bits/simd_ppc.h: Add _MaskImplPpc.
(_MaskImplPpc::_S_popcount): Implement via vec_cntm for POWER10.
Otherwise, for >=int use -vec_sums divided by a sizeof factor.
For <int use -vec_sums(vec_sum4s(...)) to sum all mask entries.
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h: Let __intrinsic_type<long
double, N> be valid if sizeof(long double) == sizeof(double) and
use a __vector double as member type.
Intrinsics types for NEON differ from gnu::vector_size types now. This
requires explicit specializations for __intrinsic_type and a new
__is_intrinsic_type trait.
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h (__is_intrinsic_type): New
internal type trait. Alias for __is_vector_type on x86.
(_VectorTraitsImpl): Enable for __intrinsic_type in addition for
__vector_type.
(__intrin_bitcast): Allow casting to & from vector & intrinsic
types.
(__intrinsic_type): Explicitly specialize for NEON intrinsic
vector types.
N3644 implies that operator- can be used on value-init iterators. We now return
0 if both iterators are value initialized. If only one is value initialized we
keep the UB by returning the result of a normal computation which is a meaningless
value.
libstdc++-v3/ChangeLog:
PR libstdc++/70303
* include/bits/stl_deque.h (std::deque<>::operator-(iterator, iterator)):
Return 0 if both iterators are value-initialized.
* testsuite/23_containers/deque/70303.cc: New test.
* testsuite/23_containers/vector/70303.cc: New test.
