The changes for PR libstdc++/64735 mean that libsupc++ function might
now depend on the __exchange_and_add and __atomic_add functions defined
in config/cpu/*/atomicity.h which is not compiled into libsupc++. This
causes a link failure for some targets when trying to use libsupc++
without the rest of libstdc++.
This patch simply moves the definitions of those functions into
libsupc++ so that they are available there.
libstdc++-v3/ChangeLog:
PR libstdc++/96657
* libsupc++/Makefile.am: Add atomicity.cc here.
* src/c++98/Makefile.am: Remove it from here.
* libsupc++/Makefile.in: Regenerate.
* src/c++98/Makefile.in: Regenerate.
* testsuite/18_support/exception_ptr/96657.cc: New test.
These deduction guides became useless with LWG 3282 (implemented in
commit r10-6741) and so were removed by LWG 3404.
libstdc++-v3/ChangeLog:
PR libstdc++/100044
* include/bits/ranges_util.h (__detail::__iterator_sentinel_pair):
Remove helper concept.
(subrange(_Pr), subrange(Pr, __make_unsigned_like<...>)): Remove
deduction guides, as per LWG 3404.
* testsuite/std/ranges/subrange/lwg3282_neg.cc: Check that class
template argument deduction fails.
The linear_congruential_engine negative tests fail with a different
error in C++20 mode, because double is no longer an invalid type for
NTTP. Adjust the expected errors.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/linear_congruential_engine/requirements/non_uint_neg.cc:
Adjust expected error for C++20 mode.
* testsuite/tr1/5_numerical_facilities/random/linear_congruential/requirements/non_uint_neg.cc:
Likewise.
The 17_intro/headers/c++1998/49745.cc test fails for C++20 mode with PCH
enabled, because PCH makes it include <bits/stdc++.h>, which includes
<atomic>, and that includes <unistd.h> in C++20 mode. The <unistd.h>
dependency should go away when C++20 atomic waiting is stable, but will
probably remain while the feature is experimental. Change the test to
always include <bits/stdc++.h>, and XFAIL for C++20 and later.
libstdc++-v3/ChangeLog:
PR libstdc++/99995
* testsuite/17_intro/headers/c++1998/49745.cc: Include all
standard headers and XFAIL for effective-target c++20.
__dp_sign precision indicates that we found out what iterator comes first or
last in the range. __dp_sign_max_size is the same plus it gives the information
of the max size of the range that is to say the max_size value such that
distance(lhs, rhs) < max_size.
Thanks to this additional information we are able to tell when a copy of n elements
to that range will fail even if we do not know exactly how large it is.
This patch makes sure that we are properly using this information.
libstdc++-v3/ChangeLog:
PR libstdc++/99402
* include/debug/helper_functions.h (__can_advance(_InputIterator,
const std::pair<_Diff, _Distance_precision>&, int)): New.
(__can_advance(const _Safe_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* include/debug/macros.h (__glibcxx_check_can_increment_dist): New,
use latter.
(__glibcxx_check_can_increment_range): Adapt to use latter.
(__glibcxx_check_can_decrement_range): Likewise.
* include/debug/safe_iterator.h
(_Safe_iterator<>::_M_can_advance(const std::pair<_Diff, _Distance_precision>&,
int)): New.
(__can_advance(const _Safe_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* include/debug/safe_iterator.tcc
(_Safe_iterator<>::_M_can_advance(const std::pair<_Diff, _Distance_precision>&,
int)): New.
(_Safe_iterator<>::_M_valid_range(const _Safe_iterator<>&,
std::pair<difference_type, _Distance_precision>&, bool)): Adapt for
__dp_sign_max_size.
(__copy_move_a): Adapt to use __glibcxx_check_can_increment_dist.
(__copy_move_backward_a): Likewise.
(__equal_aux): Likewise.
* include/debug/stl_iterator.h (__can_advance(const std::reverse_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
(__can_advance(const std::move_iterator<>&,
const std::pair<_Diff, _Distance_precision>&, int)): New.
* testsuite/25_algorithms/copy/debug/99402.cc: New test.
I keep forgetting that a constexpr function in C++11 has to be a single
return statement.
libstdc++-v3/ChangeLog:
PR libstdc++/99985
* include/bits/hashtable.h (_Hashtable::_S_nothrow_move()): Fix
to be a valid constexpr function in C++11.
* testsuite/23_containers/unordered_set/cons/99985.cc: New test.
While we're modifying elements_view, this also implements the one-line
resolution of LWG 3492.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__returnable_element): New
concept.
(elements_view): Use this concept in its constraints. Add
missing private access specifier.
(elements_view::_S_get_element): Define as per LWG 3502.
(elements_view::operator*, elements_view::operator[]): Use
_S_get_element.
(elements_view::operator++): Remove unnecessary constraint
as per LWG 3492.
* testsuite/std/ranges/adaptors/elements.cc (test05): New test.
This puts the logic for the noexcept-specifier in one place, and then
reuses it elsewhere. This means checking whether the move constructor
can throw doesn't need to do overload resolution and then check whether
some other constructor can throw, we just get the answer directly.
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h (_Hashtable::_S_nothrow_move()):
New function to determine noexcept-specifier for move
constructors.
(_Hashtable): Use _S_nothrow_move() on move constructors.
* testsuite/23_containers/unordered_map/cons/noexcept_move_construct.cc:
Correct static assertion message.
* testsuite/23_containers/unordered_multimap/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/cons/noexcept_move_construct.cc:
Likewise.
* testsuite/23_containers/unordered_set/cons/noexcept_move_construct.cc:
Likewise.
This works around the remaining reported execution FAILs of this test on
AIX, Solaris and Darwin. Eventually we should rewrite this test to be
less fragile, but there's not enough time to do that for GCC 11.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Don't run the test
on targets without a large long double. XFAIL the execution on
targets with a non-conforming printf.
This rewrites our range adaptor implementation for more comprehensible
error messages, improved SFINAE behavior and conformance to P2281.
The diagnostic improvements mostly come from using appropriately named
functors instead of lambdas in the generic implementation of partial
application and composition of range adaptors, and in the definition of
each of the standard range adaptors. This makes their pretty printed
types much shorter and more self-descriptive.
The improved SFINAE behavior comes from constraining the range adaptors'
member functions appropriately. This improvement fixes PR99433, and is
also necessary in order to implement the wording changes of P2281.
Finally, P2281 clarified that partial application and composition of
range adaptors behaves like a perfect forwarding call wrapper. This
patch implements this, except that we don't bother adding overloads for
forwarding captured state entities as non-const lvalues, since it seems
sufficient to handle the const lvalue and non-const rvalue cases for now,
given the current set of standard range adaptors. But such overloads
can be easily added if they turn out to be needed.
libstdc++-v3/ChangeLog:
PR libstdc++/99433
* include/std/ranges (__adaptor::__maybe_refwrap): Remove.
(__adaptor::__adaptor_invocable): New concept.
(__adaptor::__adaptor_partial_app_viable): New concept.
(__adaptor::_RangeAdaptorClosure): Rewrite, turning it into a
non-template base class.
(__adaptor::_RangeAdaptor): Rewrite, turning it into a CRTP base
class template.
(__adaptor::_Partial): New class template that represents
partial application of a range adaptor non-closure.
(__adaptor::__pipe_invocable): New concept.
(__adaptor::_Pipe): New class template.
(__detail::__can_ref_view): New concept.
(__detail::__can_subrange): New concept.
(all): Replace the lambda here with ...
(_All): ... this functor. Add appropriate constraints.
(__detail::__can_filter_view): New concept.
(filter, _Filter): As in all/_All.
(__detail::__can_transform): New concept.
(transform, _Transform): As in all/_All.
(__detail::__can_take_view): New concept.
(take, _Take): As in all/_All.
(__detail::__can_take_while_view): New concept.
(take_while, _TakeWhile): As in all/_All.
(__detail::__can_drop_view): New concept.
(drop, _Drop): As in all/_All.
(__detail::__can_drop_while_view): New concept.
(drop_while, _DropWhile): As in all/_All.
(__detail::__can_join_view): New concept.
(join, _Join): As in all/_All.
(__detail::__can_split_view): New concept.
(split, _Split): As in all/_All. Rename template parameter
_Fp to _Pattern.
(__detail::__already_common): New concept.
(__detail::__can_common_view): New concept.
(common, _Common): As in all/_All.
(__detail::__can_reverse_view): New concept.
(reverse, _Reverse): As in all/_All.
(__detail::__can_elements_view): New concept.
(elements, _Elements): As in all/_All.
(keys, values): Adjust.
* testsuite/std/ranges/adaptors/99433.cc: New test.
* testsuite/std/ranges/adaptors/all.cc: No longer expect that
adding empty range adaptor closure objects to a pipeline doesn't
increase the size of the pipeline.
(test05): New test.
* testsuite/std/ranges/adaptors/common.cc (test03): New test.
* testsuite/std/ranges/adaptors/drop.cc (test09): New test.
* testsuite/std/ranges/adaptors/drop_while.cc (test04): New test.
* testsuite/std/ranges/adaptors/elements.cc (test04): New test.
* testsuite/std/ranges/adaptors/filter.cc (test06): New test.
* testsuite/std/ranges/adaptors/join.cc (test09): New test.
* testsuite/std/ranges/adaptors/p2281.cc: New test.
* testsuite/std/ranges/adaptors/reverse.cc (test07): New test.
* testsuite/std/ranges/adaptors/split.cc (test01, test04):
Adjust.
(test09): New test.
* testsuite/std/ranges/adaptors/split_neg.cc (test01): Adjust
expected error message.
(test02): Likewise. Extend test.
* testsuite/std/ranges/adaptors/take.cc (test06): New test.
* testsuite/std/ranges/adaptors/take_while.cc (test05): New test.
* testsuite/std/ranges/adaptors/transform.cc (test07, test08):
New test.
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.
Calling the non-const data() member on a COW string makes it "leaked",
possibly resulting in reallocating the string to ensure a unique owner.
The path::_M_split_cmpts() member parses its _M_pathname string using
string_view objects and then calls _M_pathname.data() to find the offset
of each string_view from the start of the string. However because
_M_pathname is non-const that will cause a COW string to reallocate if
it happens to be shared with another string object. This results in the
offsets calculated for each component being wrong (i.e. undefined)
because the string views no longer refer to substrings of the
_M_pathname member. The fix is to use the parse.offset(c) member which
gets the offset safely.
The bug only happens for the path(string_type&&) constructor and only
for COW strings. When constructed from an lvalue string the string's
contents are copied rather than just incrementing the refcount, so
there's no reallocation when calling the non-const data() member. The
testsuite changes check the lvalue case anyway, because we should
probably change the deep copying to just be a refcount increment (by
adding a path(const string_type&) constructor or an overload for
__effective_range(const string_type&), for COW strings only).
libstdc++-v3/ChangeLog:
PR libstdc++/99805
* src/c++17/fs_path.cc (path::_M_split_cmpts): Do not call
non-const member on _M_pathname, to avoid copy-on-write.
* testsuite/27_io/filesystem/path/decompose/parent_path.cc:
Check construction from strings that might be shared.
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.
The calibration loop I've recently added to the libstdc++
future/members/poll.cc tests could still select iteration counts that
might yield zero-time measurements for the wait_for when ready loop.
Waiting for a future that has already had a value set is presumably
uniformly faster than a zero-timed wait for a result, so I've changed
the calibration loop to use the former.
We might still be unlucky and get nonzero from the initial loop, so
that the calibration is skipped altogether, but then get zero from the
later when-ready loop. I'm not dealing with this case in this patch.
for libstdc++-v3/ChangeLog
* testsuite/30_threads/future/members/poll.cc: Use faster
after-ready call in the calibration loop.
This makes std::random_device usable on VxWorks when running on older
x86 hardware. Since the r10-728 fix for PR libstdc++/85494 the library
will use the new code unconditionally on x86, but the cpuid checks for
RDSEED and RDRAND can fail at runtime, depending on the hardware where
the code is executing. If the OS does not provide /dev/urandom then this
means the std::random_device constructor always fails. In previous
releases if /dev/urandom is unavailable then std::mt19937 was used
unconditionally.
This patch adds a fallback for the case where the runtime cpuid checks
for x86 hardware instructions fail, and no /dev/urandom is available.
When this happens a std::linear_congruential_engine object will be used,
with a seed based on hashing the engine's address and the current time.
Distinct std::random_device objects will use different seeds, unless an
object is created and destroyed and a new object created at the same
memory location within the clock tick. This is not great, but is better
than always throwing from the constructor, and better than always using
std::mt19937 with the same seed (as GCC 9 and earlier do).
libstdc++-v3/ChangeLog:
* src/c++11/random.cc (USE_LCG): Define when a pseudo-random
fallback is needed.
[USE_LCG] (bad_seed, construct_lcg_at, destroy_lcg_at, __lcg):
New helper functions and callback.
(random_device::_M_init): Add 'prng' and 'all' enumerators.
Replace switch with fallthrough with a series of 'if' statements.
[USE_LCG]: Construct an lcg_type engine and use __lcg when cpuid
checks fail.
(random_device::_M_init_pretr1) [USE_MT19937]: Accept "prng"
token.
(random_device::_M_getval): Check for callback unconditionally
and always pass _M_file pointer.
* testsuite/26_numerics/random/random_device/85494.cc: Remove
effective-target check. Use new random_device_available helper.
* testsuite/26_numerics/random/random_device/94087.cc: Likewise.
* testsuite/26_numerics/random/random_device/cons/default-cow.cc:
Remove effective-target check.
* testsuite/26_numerics/random/random_device/cons/default.cc:
Likewise.
* testsuite/26_numerics/random/random_device/cons/token.cc: Use
new random_device_available helper. Test "prng" token.
* testsuite/util/testsuite_random.h (random_device_available):
New helper function.
The srcloc19.C testcase shows inconsistency in
std::source_location::current() locations between calls from
templates and non-templates. The location used by __builtin_source_location
comes in both cases from input_location which is set on it by bot_manip
when handling the default argument, called during finish_call_expr.
The problem is that in templates that input_location comes from the
CALL_EXPR we built earlier and that has the combined locus with
range between first character of the function name and closing paren
with caret on the opening paren, so something printed as caret as:
foobar ();
~~~~~~^~
But outside of templates, finish_call_expr is called when input_location
is just the closing paren token, i.e.
foobar ();
^
and only after that returns we create the combined location and set
the CALL_EXPR location to that. So, it means std::source_location::current()
reports in templates the column of opening (, while outside of templates
closing ).
The following patch makes it consistent by creating the combined location
already before calling finish_call_expr and temporarily overriding
input_location to that.
2021-03-25 Jakub Jelinek <jakub@redhat.com>
PR c++/99672
* parser.c (cp_parser_postfix_expression): For calls, create
combined_loc and temporarily set input_location to it before
calling finish_call_expr.
* g++.dg/concepts/diagnostic2.C: Adjust expected caret line.
* g++.dg/cpp1y/builtin_location.C (f4, n6): Move #line directives
to match locus changes.
* g++.dg/cpp2a/srcloc1.C: Adjust expected column numbers.
* g++.dg/cpp2a/srcloc2.C: Likewise.
* g++.dg/cpp2a/srcloc15.C: Likewise.
* g++.dg/cpp2a/srcloc16.C: Likewise.
* g++.dg/cpp2a/srcloc19.C: New test.
* g++.dg/modules/adhoc-1_b.C: Adjust expected column numbers
and caret line.
* g++.dg/modules/macloc-1_c.C: Adjust expected column numbers.
* g++.dg/modules/macloc-1_d.C: Likewise.
* g++.dg/plugin/diagnostic-test-expressions-1.C: Adjust expected
caret line.
* testsuite/18_support/source_location/consteval.cc (main): Adjust
expected column numbers.
* testsuite/18_support/source_location/1.cc (main): Likewise.
The testsuite utilities that use random numbers use a
default-constructed mersenne_twister_engine, meaning the values are
reproducable. This adds support for seeding them, controlledby an
environment variable. Defining GLIBCXX_SEED_TEST_RNG=val in the
environment will cause the engines to be seeded with atoi(val) if that
is non-zero, or with a value read from std::random_device otherwise.
Running with different seeds revealed some bugs in the tests, where a
randomly selected iterator was past-the-end (which can't be erased), or
where the randomly populated container was empty, and then we tried to
remove elements from it unconditionally.
libstdc++-v3/ChangeLog:
* testsuite/util/exception/safety.h (setup_base::generate):
Support seeding random engine.
(erase_point, erase_range): Adjust range of random numbers to
ensure dereferenceable iterators are used where required.
(generation_prohibited::run): Do not try to erase from empty
containers.
* testsuite/util/testsuite_containergen.h (test_containers):
Support seeding random engine.
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.
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.
For all current Darwin SDKs inttypes.h has:
extern intmax_t imaxabs(intmax_t j);
So we need to exclude j from the defined test symbols.
libstdc++-v3/ChangeLog:
* testsuite/17_intro/names.cc: Exclude j from the list
of test symbols for Darwin.
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.
This implements a minimal integer class type that emulates 128-bit
unsigned arithmetic using a pair of 64-bit integers, which the
floating-point std::to_chars implementation then uses as a drop-in
replacement for unsigned __int128 on targets that lack the latter.
After this patch, we now fully support formatting of large long double
types on such targets.
Since Ryu performs 128-bit division/modulus only by 2, 5 and 10, this
integer class type supports only these divisors rather than general
division/modulus.
libstdc++-v3/ChangeLog:
* src/c++17/floating_to_chars.cc: Simplify the file as if
__SIZEOF_INT128__ is always defined.
[!defined __SIZEOF_INT128__]: Include "uint128_t.h". Define
a base-10 to_chars overload for the uint128_t class type.
* src/c++17/uint128_t.h: New file.
* testsuite/20_util/to_chars/long_double.cc: No longer expect an
execution FAIL on targets that have a large long double type
but lack __int128.
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.
This seems to be a typo/thinko in the definition of the arrays used as
storage.
libstdc++-v3/ChangeLog:
PR libstdc++/99382
* testsuite/20_util/specialized_algorithms/uninitialized_default_n/sizes.cc:
Make storage larger than required. Verify no write to the last
element.
* testsuite/20_util/specialized_algorithms/uninitialized_value_construct_n/sizes.cc:
Likewise.
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::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.
The long double std::to_chars testcase currently verifies the
correctness of its output by comparing it to that of printf, so if
there's a mismatch between to_chars and printf, the test FAILs. This
works well for the scientific, fixed and general formatting modes,
because the corresponding printf conversion specifiers (%e, %f and %g)
are rigidly specified.
But this doesn't work well for the hex formatting mode because the
corresponding printf conversion specifier %a is more flexibly specified.
For instance, the hexadecimal forms 0x1p+0, 0x2p-1, 0x4p-2 and 0x8p-3
are all equivalent and valid outputs of the %a specifier for the number 1.
The apparent freedom here is the choice of leading hex digit -- the
standard just requires that the leading hex digit is nonzero for
normalized numbers.
Currently, our hexadecimal formatting implementation uses 0/1/2 as the
leading hex digit for floating point types that have an implicit leading
mantissa bit which in practice means all supported floating point types
except x86 long double. The latter type has a 64 bit mantissa with an
explicit leading mantissa bit, and for this type our implementation uses
the most significant four bits of the mantissa as leading hex digit.
This seems to be consistent with most printf implementations, but not
all, as PR98384 illustrates.
In order to avoid false-positive FAILs due to arbitrary disagreement
between to_chars and printf about the choice of leading hex digit, this
patch makes the testcase's verification via printf conditional on the
leading hex digits first agreeing. An additional verification step is
also added: round-tripping the output of to_chars through from_chars
should recover the value exactly.
libstdc++-v3/ChangeLog:
PR libstdc++/98384
* testsuite/20_util/to_chars/long_double.cc: Include <optional>.
(test01): Simplify verifying the nearby values by using a
2-iteration loop and a dedicated output buffer to check that the
nearby values are different. Factor out the printf-based
verification into a local function, and check that the leading
hex digits agree before comparing to the output of printf. Also
verify the output by round-tripping it through from_chars.
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.
The _wrename function won't overwrite an existing file, so use
MoveFileEx instead. That allows renaming directories over files, which
POSIX doesn't allow, so check for that case explicitly and report an
error.
Also document the deviation from the expected behaviour, and add a test
for filesystem::rename which was previously missing.
The Filesystem TS experimental::filesystem::rename doesn't have that
extra code to handle directories correctly, so the relevant parts of the
new test are not run on Windows.
libstdc++-v3/ChangeLog:
* doc/xml/manual/status_cxx2014.xml: Document implementation
specific properties of std::experimental::filesystem::rename.
* doc/xml/manual/status_cxx2017.xml: Document implementation
specific properties of std::filesystem::rename.
* doc/html/*: Regenerate.
* src/c++17/fs_ops.cc (fs::rename): Implement correct behaviour
for directories on Windows.
* src/filesystem/ops-common.h (__gnu_posix::rename): Use
MoveFileExW on Windows.
* testsuite/27_io/filesystem/operations/rename.cc: New test.
* testsuite/experimental/filesystem/operations/rename.cc: New test.
The helper function for creating new paths doesn't work well on Windows,
because the PID of a process started by Wine is very consistent and so
the same path gets created each time.
libstdc++-v3/ChangeLog:
* testsuite/util/testsuite_fs.h (nonexistent_path): Add
random number to the path.
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.
The std::emit_on_flush manipulator depends on dynamic_cast, so fails
without RTTI.
The std::async code can't catch a forced_unwind exception when RTTI is
disabled, so it can't rethrow it either, and the test aborts.
libstdc++-v3/ChangeLog:
* testsuite/27_io/basic_ostream/emit/1.cc: Expect test to fail
if -fno-rtti is used.
* testsuite/30_threads/async/forced_unwind.cc: Expect test
to abort if -fno-rtti is used.
