Somehow I pushed a different version of this test to the one I actually
tested.
libstdc++-v3/ChangeLog:
* testsuite/21_strings/basic_string/cons/char/105995.cc: Add
missing #include.
I don't think this is required by the standard, but it's easy to
support.
libstdc++-v3/ChangeLog:
PR libstdc++/105995
* include/bits/basic_string.h (_M_use_local_data): Initialize
the entire SSO buffer.
* testsuite/21_strings/basic_string/cons/char/105995.cc: New test.
As recently done for std::basic_string, __gnu_cxx::__versa_string
equality comparisons can check lengths first for any character type and
traits type, not only for std::char_traits<char>.
libstdc++-v3/ChangeLog:
PR libstdc++/101482
* include/ext/vstring.h (operator==): Always check lengths
before comparing.
As confirmed by LWG 2852, the calls to traits_type::compare do not need
to be obsvervable, so we can make operator== compare string lengths
first and return immediately for non-equal lengths. This avoids doing a
slow string comparison for "abc...xyz" == "abc...xy". Previously we only
did this optimization for std::char_traits<char>, but we can enable it
unconditionally thanks to LWG 2852.
For comparisons with a const char* we can call traits_type::length right
away to do the same optimization. That strlen call can be folded away
for constant arguments, making it very efficient.
For the pre-C++20 operator== and operator!= overloads we can swap the
order of the arguments to take advantage of the operator== improvements.
libstdc++-v3/ChangeLog:
PR libstdc++/62187
* include/bits/basic_string.h (operator==): Always compare
lengths before checking string contents.
[!__cpp_lib_three_way_comparison] (operator==, operator!=):
Reorder arguments.
Defining the compare member functions inline allows calls to
traits_type::length and std::min to be inlined, taking advantage of
constant expression arguments. When not inline, the compiler prefers to
use the explicit instantiation definitions in libstdc++.so and can't
take advantage of constant arguments.
libstdc++-v3/ChangeLog:
PR libstdc++/59048
* include/bits/basic_string.h (compare): Define inline.
* include/bits/basic_string.tcc (compare): Remove out-of-line
definitions.
* include/bits/cow_string.h (compare): Define inline.
* testsuite/21_strings/basic_string/operations/compare/char/3.cc:
New test.
The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
contain this definition in <sys/cdefs.h>:
863 #define __null_terminated
This collides with the use of __null_terminated in libstdc++'s
experimental fs_path.h.
As libstdc++'s use of this token is entirely internal to fs_path.h, the
simplest workaround, renaming it, is most appropriate. Here, it's
renamed to __nul_terminated, referencing the NUL ('\0') value that is
used to terminate the strings in the context in which this tag structure
is used.
libstdc++-v3/ChangeLog:
* include/experimental/bits/fs_path.h (__detail::__null_terminated):
Rename to __nul_terminated to avoid colliding with a macro in
Apple's SDK.
Signed-off-by: Mark Mentovai <mark@mentovai.com>
This is LWG 3220 which is about to become Tentatively Ready.
libstdc++-v3/ChangeLog:
* include/std/atomic (__atomic_val_t): Use __type_identity_t
instead of atomic<T>::value_type, as per LWG 3220.
* testsuite/29_atomics/atomic/lwg3220.cc: New test.
When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(50000, 49999) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that |m| and the result can be
represented in the return type (which is int in both those cases). The
regression occurred because __absu<unsigned>(INT_MIN) is well-formed,
due to the explicit casts to unsigned in that new helper function, and
the out-of-range multiplication is well-formed, because unsigned
arithmetic wraps instead of overflowing.
To fix 92978 I made std::gcm and std::lcm calculate |m| and |n|
immediately, yielding a common unsigned type that was used to calculate
the result. That was partly correct, but there's no need to use an
unsigned type. Doing so only suppresses the overflow errors so the
compiler can't detect them. This change replaces __absu with __abs_r
that returns the common type (not its corresponding unsigned type). This
way we can detect overflow in __abs_r when required, while still
supporting the most-negative value when it can be represented in the
result type. To detect LCM results that are out of range of the result
type we still need explicit checks, because neither constant evaluation
nor UBsan will complain about unsigned wrapping for cases such as
std::lcm(500000u, 499999u). We can detect those overflows efficiently by
using __builtin_mul_overflow and asserting.
libstdc++-v3/ChangeLog:
PR libstdc++/105844
* include/experimental/numeric (experimental::gcd): Simplify
assertions. Use __abs_r instead of __absu.
(experimental::lcm): Likewise. Remove use of __detail::__lcm so
overflow can be detected.
* include/std/numeric (__detail::__absu): Rename to __abs_r and
change to allow signed result type, so overflow can be detected.
(__detail::__lcm): Remove.
(gcd): Simplify assertions. Use __abs_r instead of __absu.
(lcm): Likewise. Remove use of __detail::__lcm so overflow can
be detected.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/105844.cc: New test.
* testsuite/26_numerics/lcm/105844.cc: New test.
This ensures that the single-threaded fallback buffer eh_globals is not
destroyed during program termination, using the same immortalization
technique used for error category objects.
Also ensure that init._M_init can still be read after init has been
destroyed, by making it a static data member.
libstdc++-v3/ChangeLog:
PR libstdc++/105880
* libsupc++/eh_globals.cc (eh_globals): Ensure constant init and
prevent destruction during termination.
(__eh_globals_init::_M_init): Replace with static member _S_init.
(__cxxabiv1::__cxa_get_globals_fast): Update.
(__cxxabiv1::__cxa_get_globals): Likewise.
This new library issue was recently moved to Tentatively Ready by an LWG
poll, so I'm making the change on trunk.
As noted in PR libstc++/105907 the std::hash specializations for PMR
strings were not treated as slow hashes by the unordered containers, so
this change preserves that. The new specializations for custom
allocators are also not treated as slow, for the same reason. For the
versioned namespace (i.e. unstable ABI) we don't have to worry about
that, so can enable hash code caching for all basic_string
specializations.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (__hash_str_base): New class
template.
(hash<basic_string<C, char_traits<C>, A>>): Define partial
specialization for each of the standard character types.
(hash<string>, hash<wstring>, hash<u8string>, hash<u16string>)
(hash<u32string>): Remove explicit specializations.
* include/std/string (__hash_string_base): Remove class
template.
(hash<pmr::string>, hash<pmr::wstring>, hash<pmr::u8string>)
(hash<pmr::u16string>, hash<pmr::u32string>): Remove explicit
specializations.
* testsuite/21_strings/basic_string/hash/hash.cc: Test with
custom allocators.
* testsuite/21_strings/basic_string/hash/hash_char8_t.cc:
Likewise.
This new function was added for gcc 11.1 but is not exported from the
shared library. Depending on inlining decisions, its callers might get
inlined but an external definition be needed for this function. That
then fails to link.
Since we can't add the export to the gcc-11 release branch now, mark it
always_inline. We can consider exporting it for gcc-13 if/when we bump
the shared library version (and maybe also for gcc-12 which is currently
at the same version as trunk). For now, the attribute will solve the
problem on all affected branches. The function is small enough that
force-inlining it shouldn't cause problems.
libstdc++-v3/ChangeLog:
PR libstdc++/105671
* include/std/sstream (basic_stringbuf::_M_high_mark): Add
always_inline attribute.
On a 16-bit target such as msp430 we get errors about narrowing long
values to size_t, which is only 16-bit. When --enable-libstdcxx-pch is
used the <bits/extc++.h> header breaks the build because of these
narrowing errors.
libstdc++-v3/ChangeLog:
PR libstdc++/105681
* include/ext/pb_ds/detail/resize_policy/hash_prime_size_policy_imp.hpp:
Limit ga_sizes array to values that fit in size_t.
* include/ext/random [__SIZE_WIDTH < 32] (sfmt86243)
(sfmt86243_64, sfmt132049, sfmt132049_64, sfmt216091)
(sfmt216091_64): Do not declare.
This fixes the printers to work with std::__8::atomic and
std::__v8::ios_errc and std::__v8::future_errc.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdErrorCodePrinter): Make
lookup for ios_errc and future_errc check versioned namespace.
(StdAtomicPrinter): Strip versioned namespace from typename.
This fixes a missing symbol when the dual ABI is disabled, e.g. for the
versioned namespace build.
libstdc++-v3/ChangeLog:
* src/c++11/Makefile.am: Add new source file.
* src/c++11/Makefile.in: Regenerate.
* src/c++11/cxx11-ios_failure.cc (iostream_category):
Move to ...
* src/c++11/ios_errcat.cc: New file.
* testsuite/27_io/ios_base/failure/error_code.cc: Check that
std::iostream_category() is defined and used for std::io_errc.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (counted_iterator::operator++(int)):
Add 'constexpr' as per LWG 3643.
* testsuite/24_iterators/counted_iterator/lwg3643.cc: New test.
This moves some #include directives to the relevant place. For example,
<bits/hashtable_policy.h> needs <bits/stl_pair.h> so should include it
directly instead of relying on <unordered_map> and <unordered_set> to do
so first.
libstdc++-v3/ChangeLog:
* include/bits/functional_hash.h (__is_fast_hash): Add doxygen
comment.
* include/bits/hashtable.h: Do not include <bits/stl_function.h>
here.
* include/bits/hashtable_policy.h: Include <bits/stl_pair.h> and
<bits/functional_hash.h>.
* include/bits/unordered_map.h: Include required headers.
* include/bits/unordered_set.h: Likewise.
* include/std/unordered_map: Do not include headers for indirect
dependencies.
* include/std/unordered_set: Likewise.
These headers do not use anything in <bits/stl_iterator_base_types.h>
directly, and it's included by <bits/stl_iterator_base_funcs.h> and
<bits/stl_iterator.h> anyway, because they do need it.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algobase.h: Do not include
<bits/stl_iterator_base_types.h>.
* include/std/string: Likewise.
* include/std/variant: Likewise.
These headers were relying on their includers having already included
some prerequisites. That makes them unsuitable to be header-units.
So directly include the needed headers.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:
* include/bits/hashtable.h: Include required headers.
* include/bits/hashtable_policy.h: Likewise.
* include/bits/stl_heap.h: Likewise.
* include/bits/stl_iterator_base_funcs.h: Likewise.
Repeating "explicit_instantiation" in these long pathnames is not
necessary.
libstdc++-v3/ChangeLog:
* testsuite/20_util/duration/requirements/explicit_instantiation/explicit_instantiation.cc:
Moved to...
* testsuite/20_util/duration/requirements/explicit_instantiation.cc: ...here.
* testsuite/20_util/time_point/requirements/explicit_instantiation/explicit_instantiation.cc:
Moved to...
* testsuite/20_util/time_point/requirements/explicit_instantiation.cc: ...here.
* testsuite/20_util/unique_ptr/requirements/explicit_instantiation/explicit_instantiation.cc:
Moved to...
* testsuite/20_util/unique_ptr/requirements/explicit_instantiation.cc: ...here.
A change I was working on made constexpr_searcher.cc start to fail, and when
I looked at it I wondered why it had been accepted before. This turned out
to be because we try to be more flexible about constant-evaluation of static
initializers, as allowed, but we were wrongly doing the same for non-static
initializers as well.
gcc/cp/ChangeLog:
* constexpr.cc (maybe_constant_init_1): Only pass false for
strict when initializing a variable of static duration.
libstdc++-v3/ChangeLog:
* testsuite/20_util/function_objects/constexpr_searcher.cc: Add
constexpr.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/constexpr-local4.C: New test.
Some of these tests take several minutes on a simulator like cris-elf,
so we can conditionally run fewer iterations. The testDiscreteDist
helper already supports custom sizes so we just need to make use of that
when { target simulator } matches.
The relevant code is sufficiently tested on other targets, so we're not
losing anything by only running a small number of iterators for sims.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc:
Run fewer iterations for simulator targets.
* testsuite/26_numerics/random/binomial_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/discrete_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/geometric_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/poisson_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/uniform_int_distribution/operators/values.cc:
Likewise.
We should prefer the __UINT_LEAST16_TYPE__ and __UINT_LEAST32_TYPE__
macros, if available, so that we don't need all of <cstdint> in every
header that uses std::char_traits.
libstdc++-v3/ChangeLog:
* include/bits/char_traits.h: Only include <cstdint> when
necessary.
* include/std/stacktrace: Use __UINTPTR_TYPE__ instead of
uintptr_t.
* src/c++11/cow-stdexcept.cc: Include <stdint.h>.
* src/c++17/floating_to_chars.cc: Likewise.
* testsuite/20_util/assume_aligned/1.cc: Include <cstdint>.
* testsuite/20_util/assume_aligned/3.cc: Likewise.
* testsuite/20_util/shared_ptr/creation/array.cc: Likewise.
Since the COW std::string was moved to its own header, we don't need the
atomic dispatch helpers in the definition of std::__cxx11::string. Move
the inclusion of the <ext/atomicity.h> header to <bits/cow_string.h>
where it's needed.
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h: Do not include <ext/atomicity.h>
here.
* include/bits/cow_string.h: Include it here.
Currently the alias templates for std::pmr::vector, std::pmr::string
etc. are defined using a forward declaration for polymorphic_allocator.
This means you can't actually use the alias templates unless you also
include <memory_resource>. The rationale for that is that it's a fairly
large header, and most users don't need it. This isn't uncontroversial
though, and LWG 3681 questions whether it's even conforming.
This change adds a new <bits/memory_resource.h> header with the minimum
needed to use polymorphic_allocator and the std::pmr container aliases.
Including <memory_resource> is still necessary to use the program-wide
resource objects, or the pool resources or monotonic buffer resource.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/memory_resource.h: New file.
* include/std/deque: Include <bits/memory_resource.h>.
* include/std/forward_list: Likewise.
* include/std/list: Likewise.
* include/std/map: Likewise.
* include/std/memory_resource (pmr::memory_resource): Move to
new <bits/memory_resource.h> header.
(pmr::polymorphic_allocator): Likewise.
* include/std/regex: Likewise.
* include/std/set: Likewise.
* include/std/stacktrace: Likewise.
* include/std/string: Likewise.
* include/std/unordered_map: Likewise.
* include/std/unordered_set: Likewise.
* include/std/vector: Likewise.
* testsuite/21_strings/basic_string/types/pmr_typedefs.cc:
Remove <memory_resource> header and check construction.
* testsuite/23_containers/deque/types/pmr_typedefs.cc: Likewise.
* testsuite/23_containers/forward_list/pmr_typedefs.cc:
Likewise.
* testsuite/23_containers/list/pmr_typedefs.cc: Likewise.
* testsuite/23_containers/map/pmr_typedefs.cc: Likewise.
* testsuite/23_containers/multimap/pmr_typedefs.cc: Likewise.
* testsuite/23_containers/multiset/pmr_typedefs.cc: Likewise.
* testsuite/23_containers/set/pmr_typedefs.cc: Likewise.
* testsuite/23_containers/unordered_map/pmr_typedefs.cc:
Likewise.
* testsuite/23_containers/unordered_multimap/pmr_typedefs.cc:
Likewise.
* testsuite/23_containers/unordered_multiset/pmr_typedefs.cc:
Likewise.
* testsuite/23_containers/unordered_set/pmr_typedefs.cc:
Likewise.
* testsuite/23_containers/vector/pmr_typedefs.cc: Likewise.
* testsuite/28_regex/match_results/pmr_typedefs.cc: Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/variadic-tuple.C: Qualify function to avoid ADL
finding std::make_tuple.
This issue has recently been moved to Tentatively Ready, and seems
uncontroversial. This allows equality comparison with types that are
convertible to pmr::polymorphic_allocator, which fail deduction for the
existing equality operator.
libstdc++-v3/ChangeLog:
* include/std/memory_resource (polymorphic_allocator): Add
non-template equality operator, as proposed for LWG 3683.
* testsuite/20_util/polymorphic_allocator/lwg3683.cc: New test.
Currently pmr::set_default_resource and pmr::get_default_resource both
use sequentially consistent memory ordering. This is overkill. The
standard only requires that a call to set_default_resource synchronizes
with subsequent calls to set_default_resource and get_default_resource.
Using acquire-release for the setter and acquire for the getter is
sufficient to meet the requirement.
Reviewed-by: Thomas Rodgers <trodgers@redhat.com>
libstdc++-v3/ChangeLog:
* src/c++17/memory_resource.cc (set_default_resource): Use
memory_order_acq_rel.
(get_default_resource): Use memory_order_acquire.
Add attributes to the accessors for the global memory resource objects,
to allow the compiler to eliminate redundant calls to them. For example,
multiple calls to std::pmr::new_delete_resource() will always return the
same object, and so the compiler can replace them with a single call.
Ideally we would like adjacent calls to std::pmr::get_default_resource()
to be combined into a single call by the CSE pass. The 'pure' attribute
would permit that. However, the standard requires that calls to
std::pmr::set_default_resource() synchronize with subsequent calls to
std::pmr::get_default_resource(). With 'pure' the DCE pass might
eliminate seemingly redundant calls to std::pmr::get_default_resource().
That might be unsafe, because the caller might be relying on the
associated synchronization. We could use a hypothetical attribute that
allows CSE but not DCE, but we don't have one. So it can't be 'pure'.
Also add [[nodiscard]] to equality operators.
libstdc++-v3/ChangeLog:
* include/std/memory_resource (new_delete_resource): Add
nodiscard, returns_nonnull and const attributes.
(null_memory_resource): Likewise.
(set_default_resource, get_default_resource): Add returns_nonnull
attribute.
(memory_resource::is_equal): Add nodiscard attribute.
(operator==, operator!=): Likewise.
Add the const attribute to std::future_category() and
std::iostream_category(), to match the existing attributes on
std::generic_category() and std::system_category().
Also add [[nodiscard]] to those functions and to the comparison
operators for std::error_code and std::error_condition, and to
std::make_error_code and std::make_error_condition overloads.
libstdc++-v3/ChangeLog:
* include/bits/ios_base.h (io_category): Add const and nodiscard
attributes.
(make_error_code, make_error_condition): Add nodiscard.
* include/std/future (future_category): Add const and nodiscard.
(make_error_code, make_error_condition): Add nodiscard.
* include/std/system_error (generic_category system_category):
Add nodiscard. Replace _GLIBCXX_CONST with C++11 attribute.
(error_code::value, error_code::category, error_code::operator bool)
(error_condition::value, error_condition::category)
(error_condition::operator bool, make_error_code)
(make_error_condition, operator==, operator!=, operator<=>): Add
nodiscard.
Most tests for the contents of header synopses need to be supressed for
the versioned namespace build, because redeclaring the entities in std
fails when they were originally declared in std::__8.
I added these tests recently without the suppression, so they fail.
libstdc++-v3/ChangeLog:
* testsuite/20_util/expected/synopsis.cc: Skip for versioned
namespace.
* testsuite/27_io/headers/iosfwd/synopsis.cc: Likewise.
The src/c++11/compatibility*-c++0x.cc files define symbols that need to
be exported for ancient versions of libstdc++.so.6 due to changes
between C++0x and the final C++11 standard. Those symbols are not needed
in the libstdc++.so.8 library, and we can skip building them entirely.
This also fixes the build failure I introduced last week when making the
versioned namespace config not use the _V2 namespace for compat symbols.
libstdc++-v3/ChangeLog:
* src/Makefile.am [ENABLE_SYMVERS_GNU_NAMESPACE] (cxx11_sources):
Do not build the compatibility*-c++0x.cc objects.
* src/Makefile.in: Regenerate.
* src/c++11/compatibility-c++0x.cc [_GLIBCXX_INLINE_VERSION]:
Refuse to build for the versioned namespace.
* src/c++11/compatibility-chrono.cc: Likewise.
* src/c++11/compatibility-condvar.cc: Likewise.
* src/c++11/compatibility-thread-c++0x.cc: Likewise.
* src/c++11/chrono.cc (system_clock, steady_clock):
Use macros to define in inline namespace _V2, matching the
declarations in <system_error>.
* src/c++11/system_error.cc (system_category, generic_category):
Likewise.
