aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3
AgeCommit message (Collapse)AuthorFilesLines
2024-08-24Daily bump.GCC Administrator1-0/+108
2024-08-23libstdc++: Update and clarify Doxygen version requirements in manualJonathan Wakely6-10/+11
There are lots of bugs that affect libstdc++ output from Doxygen, so using 1.9.6 or later is recommended. Give a lower minimum, because some distros still use 1.9.1 and that will work, albeit suboptimally. libstdc++-v3/ChangeLog: * doc/xml/manual/documentation_hacking.xml: Update minimum Doxygen version. * doc/html/*: Regenerate.
2024-08-23libstdc++: Hide std::tuple internals from Doxygen docsJonathan Wakely1-0/+2
libstdc++-v3/ChangeLog: * include/std/tuple: Do not include implementation details in Doxygen documentation.
2024-08-23libstdc++: Improve Doxygen docs for std::allocator_traits specializationsJonathan Wakely2-4/+21
The main fix here is to use @header so that the docs show the correct header file instead of an internal header like alloc_traits.h. libstdc++-v3/ChangeLog: * include/bits/alloc_traits.h: Improve doxygen docs for allocator_traits specializations. * include/bits/memory_resource.h: Likewise.
2024-08-23libstdc++: Implement LWG 3746 for std::optionalJonathan Wakely2-2/+30
This avoids constraint recursion in operator<=> for std::optional. The resolution was approved in Kona 2022. libstdc++-v3/ChangeLog: * include/std/optional (__is_derived_from_optional): New concept. (operator<=>): Use __is_derived_from_optional. * testsuite/20_util/optional/relops/lwg3746.cc: New test.
2024-08-23libstdc++: Optimize __try_use_facet for const typesJonathan Wakely1-1/+1
LWG 436 confirmed that const-qualified types are valid arguments for Facet template parameters (but volatile-qualified types are not). Use the fast path in std::use_facet and std::has_facet for const T as well as T. libstdc++-v3/ChangeLog: * include/bits/locale_classes.tcc (__try_use_facet): Also avoid dynamic_cast for const-qualified facet types.
2024-08-23libstdc++: Fix std::allocator_traits::construct constraints [PR108619]Jonathan Wakely8-133/+314
Using std::is_constructible in the constraints introduces a spurious dependency on the type being destructible, which should not be required for constructing with an allocator. The test case shows a case where the type has a private destructor, which can be destroyed by the allocator, but std::is_destructible and std::is_constructible are false. Similarly, using is_nothrow_constructible in the noexcept-specifiers for the construct members of allocator_traits and std::allocator, __gnu_cxx::__new_allocator, and __gnu_cxx::__malloc_allocator gives the wrong answer if the type isn't destructible. We need a new type trait to define those correctly, so that we only check if the placement new-expression is nothrow after using is_constructible to check that it would be well-formed. Instead of just fixing the overly restrictive constraint to check for placement new, rewrite allocator_traits in terms of 'if constexpr' using variable templates and the detection idiom. Although we can use 'if constexpr' and variable templates in C++11 with appropriate uses of diagnostic pragmas, we can't have constexpr functions with multiple return statements. This means that in C++11 mode the _S_nothrow_construct and _S_nothrow_destroy helpers used for noexcept-specifiers still need to be overlaods using enable_if. Nearly everything else can be simplified to reduce overload resolution and enable_if checks. libstdc++-v3/ChangeLog: PR libstdc++/108619 * include/bits/alloc_traits.h (__allocator_traits_base): Add variable templates for detecting which allocator operations are supported. (allocator_traits): Use 'if constexpr' instead of dispatching to overloads constrained with enable_if. (allocator_traits<allocator<T>>::construct): Use Construct if construct_at is not supported. Use __is_nothrow_new_constructible for noexcept-specifier. (allocator_traits<allocator<void>>::construct): Use __is_nothrow_new_constructible for noexcept-specifier. * include/bits/new_allocator.h (construct): Likewise. * include/ext/malloc_allocator.h (construct): Likewise. * include/std/type_traits (__is_nothrow_new_constructible): New variable template. * testsuite/20_util/allocator/89510.cc: Adjust expected results. * testsuite/ext/malloc_allocator/89510.cc: Likewise. * testsuite/ext/new_allocator/89510.cc: Likewise. * testsuite/20_util/allocator_traits/members/108619.cc: New test.
2024-08-23libstdc++: Only use std::time_put in std::format for non-C localesJonathan Wakely1-59/+74
When testing on Solaris I noticed that std/time/year/io.cc was FAILing because the year 1642 was being formatted as "+(" by %Ey. This turns out to be because we defer to std::time_put for modified conversion specs, and std::time_put uses std::strftime, and that's undefined for years before 1970. In particular, years before 1900 mean that the tm_year field is negative, which then causes incorrect results from strftime on at least Solaris and AIX. I've raised the general problem with LWG, but we can fix the FAILing test case (and probably improve performance slightly) by ignoring the E and O modifiers when the formatting locale is the "C" locale. The modifiers have no effect for the C locale, so we can just treat %Ey as %y and format it directly. This doesn't fix anything when the formatting locale isn't the C locale, but that case is not adequately tested, so doesn't cause any FAIL right now! The naïve fix would be simply: if (__mod) if (auto __loc = _M_locale(__ctx); __loc != locale::classic()) // ... However when the format string doesn't use the 'L' option, _M_locale always returns locale::classic(). In that case, we make a copy of the classic locale (which calls the non-inline copy constructor in the library), then make another copy of the classic locale, then compare the two. We can avoid all that by checking for the 'L' option first, instead of letting _M_locale do that: if (__mod && _M_spec._M_localized) if (auto __loc = __ctx.locale(); __loc != locale::classic()) // ... We could optimize this further if we had a __is_classic(__loc) function that would do the __loc == locale::classic() check without making any copies or non-inline calls. That would require examining the locale's _M_impl member, and probably require checking its name, because the locale::_S_classic singleton is not exported from the library. For _M_S the change is slightly different from the other functions, because if we skip using std::time_put for %OS then we fall through to the code that potentially prints fractional seconds, but the %OS format only prints whole seconds. So we need to format whole seconds directly when not using std::time_put, instead of falling through to the code below. libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (__formatter_chrono::_M_C_y_Y): Ignore modifiers unless the formatting locale is not the C locale. (__formatter_chrono::_M_d_e): Likewise. (__formatter_chrono::_M_H_I): Likewise. (__formatter_chrono::_M_m): Likewise. (__formatter_chrono::_M_M): Likewise. (__formatter_chrono::_M_S): Likewise. (__formatter_chrono::_M_u_w): Likewise. (__formatter_chrono::_M_U_V_W): Likewise.
2024-08-23libstdc++: Define operator== for hash table iterators [PR115939]Jonathan Wakely2-2/+107
Currently iterators for unordered containers do not directly define operator== and operator!= overloads. Instead they rely on the base class defining them, which is done so that iterator and const_iterator comparisons work using the same overloads. However this means a derived-to-base conversion is needed to call those operators, and PR libstdc++/115939 shows that this can be ambiguous (for -pedantic) when another overloaded operator could be used after an implicit conversion. This change defines operator== and operator!= directly for _Node_iterator and _Node_const_iterator so that no derived-to-base conversions are needed. The new overloads just forward to the base class ones, so the implementation is still shared and doesn't need to be duplicated. libstdc++-v3/ChangeLog: PR libstdc++/115939 * include/bits/hashtable_policy.h (_Node_iterator): Add operator== and operator!=. (_Node_const_iterator): Likewise. * testsuite/23_containers/unordered_map/115939.cc: New test.
2024-08-23libstdc++: Fix std::random_shuffle for low RAND_MAX [PR88935]Giovanni Bajo2-9/+57
When RAND_MAX is small and the number of elements being shuffled is close to it, we get very uneven distributions in std::random_shuffle. This uses a simple xorshift generator seeded by std::rand if we can't rely on std::rand itself. libstdc++-v3/ChangeLog: PR libstdc++/88935 * include/bits/stl_algo.h (random_shuffle) [RAND_MAX < INT_MAX]: Use xorshift instead of rand(). * testsuite/25_algorithms/random_shuffle/88935.cc: New test. Co-authored-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Giovanni Bajo <rasky@develer.com>
2024-08-23libstdc++: Make debug sequence members mutable [PR116369]Jonathan Wakely1-2/+2
We need to be able to attach debug mode iterators to const containers, so the safe iterator constructor uses const_cast to get a modifiable pointer to the container. If the container was defined as const, that const_cast to access its members results in undefined behaviour. PR 116369 shows a case where it results in a segfault because the container is in a rodata section (which shouldn't have happened, but the undefined behaviour in the library still exists in any case). This makes the _M_iterators and _M_const_iterators data members mutable, so that it's safe to modify them even if the declared type of the container is a const type. Ideally we would not need the const_cast at all. Instead, the _M_attach member (and everything it calls) should be const-qualified. That would work fine now, because the members that it ends up modifying are mutable. Making that change would require a number of new exports from the shared library, and would require retaining the old non-const member functions (maybe as symbol aliases) for backwards compatibility. That might be worth changing at some point, but isn't done here. libstdc++-v3/ChangeLog: PR c++/116369 * include/debug/safe_base.h (_Safe_sequence_base::_M_iterators): Add mutable specifier. (_Safe_sequence_base::_M_const_iterators): Likewise.
2024-08-23libstdc++: Use noexcept insted of throw() in src/c++11/debug.ccJonathan Wakely1-16/+16
libstdc++-v3/ChangeLog: * src/c++11/debug.cc: Replace throw() with noexcept.
2024-08-23libstdc++: Simplify C++20 implementation of std::variantJonathan Wakely1-46/+37
For C++20 the __detail::__variant::_Uninitialized primary template can be used for all types, because _Variant_union can have a non-trivially destructible union member in C++20, and the constrained user-provided destructor will ensure we don't destroy inactive objects. Since we always use the primary template for C++20, we don't need the _Uninitialized::_M_get accessors to abstract the difference between the primary template and the partial specialization. That allows us to simplify __get_n for C++20 too. Also improve the comments that explain the uses of _Uninitialized and when/why _Variant_union needs a user-provided destructor. libstdc++-v3/ChangeLog: * include/std/variant [C++20] (_Uninitialized): Always use the primary template. [C++20] (__get_n): Access the _M_storage member directly.
2024-08-23libstdc++: Make std::vector<bool>::reference constructor private [PR115098]Jonathan Wakely4-7/+29
The standard says this constructor should be private. LWG 4141 proposes to remove it entirely. We still need it, but it doesn't need to be public. For std::bitset the default constructor is already private (and never even defined) but there's a non-standard constructor that's public, but doesn't need to be. libstdc++-v3/ChangeLog: PR libstdc++/115098 * include/bits/stl_bvector.h (_Bit_reference): Make default constructor private. Declare vector and bit iterators as friends. * include/std/bitset (bitset::reference): Make constructor and data members private. * testsuite/20_util/bitset/115098.cc: New test. * testsuite/23_containers/vector/bool/115098.cc: New test.
2024-08-23Daily bump.GCC Administrator1-0/+54
2024-08-22libstdc++: Add some missing ranges feature-test macro testsPatrick Palka3-0/+12
libstdc++-v3/ChangeLog: * testsuite/25_algorithms/contains/1.cc: Verify value of __cpp_lib_ranges_contains. * testsuite/25_algorithms/find_last/1.cc: Verify value of __cpp_lib_ranges_find_last. * testsuite/26_numerics/iota/2.cc: Verify value of __cpp_lib_ranges_iota. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-08-22libstdc++: Optimize std::projected<I, std::identity>Patrick Palka2-0/+10
Algorithms that are generalized to take projections typically default the projection to std::identity, which is equivalent to no projection at all. In that case, I believe we could shortcut the projection logic to return the iterator unchanged rather than wrapping it. This should reduce compile times especially after P2609R3 which made the indirect invocability concepts more expensive to check when actual projections are involved. libstdc++-v3/ChangeLog: * include/bits/iterator_concepts.h (__detail::__projected): Define an optimized partial specialization for when the projection is std::identity. * testsuite/24_iterators/indirect_callable/projected.cc: Verify the optimization. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-08-22libstdc++: Implement P2997R1 changes to the indirect invocability conceptsPatrick Palka6-85/+57
This implements the changes of this C++26 paper as a DR against C++20. In passing this patch removes the std/ranges/version_c++23.cc test which is now mostly obsolete after the version.def FTM refactoring, and instead expands the __cpp_lib_ranges checks in another test so that it verifies the exact value of the FTM on a per language version basis. libstdc++-v3/ChangeLog: * include/bits/iterator_concepts.h (indirectly_unary_invocable): Relax as per P2997R1. (indirectly_regular_unary_invocable): Likewise. (indirect_unary_predicate): Likewise. (indirect_binary_predicate): Likewise. (indirect_equivalence_relation): Likewise. (indirect_strict_weak_order): Likewise. * include/bits/version.def (ranges): Update value for C++26. * include/bits/version.h: Regenerate. * testsuite/24_iterators/indirect_callable/p2997r1.cc: New test. * testsuite/std/ranges/version_c++23.cc: Remove. * testsuite/std/ranges/headers/ranges/synopsis.cc: Refine the __cpp_lib_ranges checks. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-08-22libstdc++: Implement P2609R3 changes to the indirect invocability conceptsPatrick Palka5-19/+77
This implements the changes of this C++23 paper as a DR against C++20. Note that after the later P2538R1 "ADL-proof std::projected" (which we already implement), we can't use a simple partial specialization to match specializations of the 'projected' alias template. So instead we identify such specializations using a pair of distinguishing member aliases. libstdc++-v3/ChangeLog: * include/bits/iterator_concepts.h (__detail::__indirect_value): Define. (__indirect_value_t): Define as per P2609R3. (iter_common_reference_t): Adjust as per P2609R3. (indirectly_unary_invocable): Likewise. (indirectly_regular_unary_invocable): Likewise. (indirect_unary_predicate): Likewise. (indirect_binary_predicate): Likewise. (indirect_equivalence_relation): Likewise. (indirect_strict_weak_order): Likewise. (__detail::__projected::__type): Define member aliases __projected_Iter and __projected_Proj providing the template arguments of the current specialization. * include/bits/version.def (ranges): Update value. * include/bits/version.h: Regenerate. * testsuite/24_iterators/indirect_callable/p2609r3.cc: New test. * testsuite/std/ranges/version_c++23.cc: Update expected value of __cpp_lib_ranges macro. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-08-22Daily bump.GCC Administrator1-0/+20
2024-08-21libstdc++: Use strlen for std::char_traits<char8_t>::length [PR102958]Jonathan Wakely1-4/+1
libstdc++-v3/ChangeLog: PR tree-optimization/102958 * include/bits/char_traits.h (char_traits<char8_t>::length): Use strlen.
2024-08-21libstdc++: Check ios::uppercase for ios::fixed floating-point output [PR114862]Jonathan Wakely2-5/+54
This is LWG 4084 which I filed recently. LWG seems to support making the change, so that std::num_put can use the %F format for floating-point numbers. libstdc++-v3/ChangeLog: PR libstdc++/114862 * src/c++98/locale_facets.cc (__num_base::_S_format_float): Check uppercase flag for fixed format. * testsuite/22_locale/num_put/put/char/lwg4084.cc: New test.
2024-08-21libstdc++: Fix std::variant to reject array types [PR116381]Jonathan Wakely2-4/+19
libstdc++-v3/ChangeLog: PR libstdc++/116381 * include/std/variant (variant): Fix conditions for static_assert to match the spec. * testsuite/20_util/variant/types_neg.cc: New test.
2024-08-21Daily bump.GCC Administrator1-0/+14
2024-08-20libstdc++: Remove redundant reclaration of std::optionalJonathan Wakely1-3/+0
We've already declared optional at the top of the header, so don't need to do it again. libstdc++-v3/ChangeLog: * include/std/optional: Remove redundant redeclaration.
2024-08-20libstdc++: Fix indentation of lines that follow a [[likely]] attributeJonathan Wakely1-2/+2
libstdc++-v3/ChangeLog: * include/std/text_encoding: Fix indentation.
2024-08-20libstdc++: Adjust testcase for constexpr placement new [PR115744]Jonathan Wakely1-2/+7
This test now fails in C++26 mode because the declaration in <new> is constexpr and the one in the test isn't. Add constexpr to the test. libstdc++-v3/ChangeLog: PR libstdc++/115744 * testsuite/18_support/headers/new/synopsis.cc [C++26]: Add constexpr to placement operator new and operator new[].
2024-08-19Daily bump.GCC Administrator1-0/+6
2024-08-18libstdc++: Remove note from the GCC 4.0.1 daysGerald Pfeifer2-8/+2
libstdc++-v3: * doc/xml/manual/prerequisites.xml: Remove note from the GCC 4.0.1 days. * doc/html/manual/setup.html: Regenerate.
2024-08-18Daily bump.GCC Administrator1-0/+24
2024-08-17libstdc++: Update references to gcc.gnu.org/onlinedocsGerald Pfeifer13-17/+17
libstdc++-v3: * doc/xml/manual/abi.xml: Update reference to gcc.gnu.org/onlinedocs. * doc/xml/manual/concurrency_extensions.xml (interface): Ditto. * doc/xml/manual/extensions.xml: Ditto. * doc/xml/manual/parallel_mode.xml: Ditto. * doc/xml/manual/shared_ptr.xml: Ditto. * doc/xml/manual/using_exceptions.xml: Ditto. And change GNU GCC to GCC. * doc/html/manual/abi.html: Regenerate. * doc/html/manual/ext_concurrency_impl.html: Ditto. * doc/html/manual/ext_demangling.html: Ditto. * doc/html/manual/memory.html: Ditto. * doc/html/manual/parallel_mode_design.html: Ditto. * doc/html/manual/parallel_mode_using.html: Ditto. * doc/html/manual/using_exceptions.html: Ditto.
2024-08-17libstdc++: Tweak links to installation docsGerald Pfeifer2-5/+6
libstdc++v-3: * doc/xml/manual/prerequisites.xml: Tweak two links to installation docs. Fix grammar. * doc/html/manual/setup.html: Regenerate.
2024-08-17Daily bump.GCC Administrator1-0/+11
2024-08-16libstdc++-v3: Handle iconv as optional for newlib builds [PR116362]Hans-Peter Nilsson2-2/+34
Support for iconv in newlib seems to have been always assumed present by libstdc++-v3, but is default off. Though, it hasn't been used before recent libstdc++ changes that actually call iconv functions. This now leads to failures exposed by running the test-suite, unless the newlib being used has been explicitly configured with --enable-newlib-iconv. When failing, there are undefined references to iconv, iconv_open or iconv_close for multiple tests. Thankfully there's a macro in newlib.h that we can check to detect presence of iconv support for the newlib build that's used. libstdc++-v3: PR libstdc++/116362 * configure.ac: Check newlib configuration whether iconv is enabled. * configure: Regenerate.
2024-08-16libstdc++-v3: testsuite: Prune uncapitalized "in function" linker warningHans-Peter Nilsson1-0/+9
Newer newlib trigger warnings about certain functions not implemented (_getentropy) when testing libstdc++-v3. Since 2018 (circa binutils-2.31) the "in function" prefix isn't capitalized for those "not implemented" warnings when generated from the linker (a GNU ld feature used by newlib). Dejagnu up to and including at least dejagnu-1.6.3 (and git @ 42979bd3b9) assumes a capital "In function", leaving that part unpruned, and boom we have thousands of "excess errors" from the libstdc++-v3 testsuite. While gcc/testsuite/lib/prune.exp:prune_gcc_output already deals with this quirk with a vastly more generic pattern, I choose this simpler tweak. libstdc++-v3: * testsuite/lib/prune.exp (libstdc++-dg-prune): Prune uncapitalized "in function" warning from linker.
2024-08-09Daily bump.GCC Administrator1-0/+11
2024-08-08c++, libstdc++: Implement C++26 P2747R2 - constexpr placement new [PR115744]Jakub Jelinek3-2/+32
With the PR115754 fix in, constexpr placement new mostly just works, so this patch just adds constexpr keyword to the placement new operators in <new>, adds FTMs and testsuite coverage. There is one accepts-invalid though, the new (p + 1) int[]{2, 3}; // error (in this paper) case from the paper. Can we handle that incrementally? The problem with that is I think calling operator new now that it is constexpr should be fine even in that case in constant expressions, so int *p = std::allocator<int>{}.allocate(3); int *q = operator new[] (sizeof (int) * 2, p + 1); should be ok, so it can't be easily the placement new operator call itself on whose constexpr evaluation we try something special, it should be on the new expression, but constexpr.cc actually sees only <<< Unknown tree: expr_stmt (void) (TARGET_EXPR <D.2640, (void *) TARGET_EXPR <D.2641, VIEW_CONVERT_EXPR<int *>(b) + 4>>, TARGET_EXPR <D.2642, operator new [] (8, NON_LVALUE_EXPR <D.2640>)>, int * D.2643; <<< Unknown tree: expr_stmt (void) (D.2643 = (int *) D.2642) >>>; and that is just fine by the preexisting constexpr evaluation rules. Should build_new_1 emit some extra cast for the array cases with placement new in maybe_constexpr_fn (current_function_decl) that the existing P2738 code would catch? 2024-08-08 Jakub Jelinek <jakub@redhat.com> PR c++/115744 gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Change __cpp_constexpr from 202306L to 202406L for C++26. gcc/testsuite/ * g++.dg/cpp2a/construct_at.h (operator new, operator new[]): Use constexpr instead of inline if __cpp_constexpr >= 202406L. * g++.dg/cpp26/constexpr-new1.C: New test. * g++.dg/cpp26/constexpr-new2.C: New test. * g++.dg/cpp26/constexpr-new3.C: New test. * g++.dg/cpp26/feat-cxx26.C (__cpp_constexpr): Adjust expected value. libstdc++-v3/ * libsupc++/new (__glibcxx_want_constexpr_new): Define before including bits/version.h. (_GLIBCXX_PLACEMENT_CONSTEXPR): Define. (operator new, operator new[]): Use it for placement new instead of inline. * include/bits/version.def (constexpr_new): New FTM. * include/bits/version.h: Regenerate.
2024-08-07Daily bump.GCC Administrator1-0/+8
2024-08-06libstdc++: Fix some undeclared uses of uintptr_t [PR116247]Jonathan Wakely3-1/+3
libstdc++-v3/ChangeLog: PR libstdc++/116247 * include/bits/fs_path.h: Use __UINTPTR_TYPE__ instead of uintptr_t. * include/bits/shared_ptr_atomic.h: Likewise. * include/ext/pointer.h: Include <stdint.h>.
2024-08-04Daily bump.GCC Administrator1-0/+8
2024-08-03libstdc++: use concrete return type for std::forward_likePatrick Palka2-27/+26
Inspired by https://github.com/llvm/llvm-project/issues/101614 this inverts the relationship between forward_like and __like_t so that forward_like is defined in terms of __like_t and with a concrete return type. __like_t in turn is defined via partial specializations that pattern match on the const- and reference-ness of T. This turns out to be more SFINAE friendly and significantly cheaper to compile than the previous implementation. libstdc++-v3/ChangeLog: * include/bits/move.h (__like_impl): New metafunction. (__like_t): Redefine in terms of __like_impl. (forward_like): Redefine in terms of __like_t. * testsuite/20_util/forward_like/2_neg.cc: Don't expect error outside the immediate context anymore. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2024-08-03Daily bump.GCC Administrator1-0/+5
2024-08-02libstdc++: Add missing <cstdint> to testJonathan Wakely1-0/+1
libstdc++-v3/ChangeLog: * testsuite/libstdc++-prettyprinters/shared_ptr.cc: Include <cstdint>.
2024-08-02Daily bump.GCC Administrator1-0/+53
2024-08-01libstdc++: Remove unused helper traitsJonathan Wakely2-10/+0
These are not used anywhere, we have more efficient variable templates for them instead. They're not documented as extensions, and are easy for users to write if they need them. libstdc++-v3/ChangeLog: * include/bits/utility.h (__is_in_place_type): Remove. * include/std/variant (__is_in_place_tag): Remove.
2024-08-01libstdc++: Remove unnecessary uses of <stdint.h>Jonathan Wakely4-10/+17
We don't need to include all of <stdint.h> when we only need uintptr_t from it. By using GCC's internal macro we avoid unnecessarily declaring everything in <stdint.h>. This helps users to avoid accidentally relying on those names being declared without explicitly including the header. libstdc++-v3/ChangeLog: * include/bits/align.h (align, assume_aligned): Use __UINTPTR_TYPE__ instead of uintptr_t. Do not include <stdint.h>. * include/bits/atomic_base.h (__atomic_ref): Likewise. * include/bits/atomic_wait.h (__waiter_pool_base::_S_for): Likewise. * include/std/atomic: Include <cstdint>.
2024-08-01libstdc++: Remove unused parameters from atomic impl detailsJonathan Wakely1-4/+2
libstdc++-v3/ChangeLog: * include/bits/atomic_base.h (__atomic_impl::compare_exchange_weak): Remove unused parameter. (__atomic_impl::compare_exchange_strong): Likewise.
2024-08-01libstdc++: Use memcmp to optimize std::bitset::_M_is_equal() [PR113807]Jonathan Wakely1-4/+10
As noted in the PR the compiler doesn't seem able to do this on its own, so we get better code at all optimization levels by using memcmp. libstdc++-v3/ChangeLog: PR libstdc++/113807 * include/std/bitset (bitset::_M_is_equal()): Use memcmp to optimize operator==.
2024-08-01libstdc++: Fix incomplete change to reduce iterations for simulatorsJonathan Wakely1-3/+3
This should have been done as part of r13-693-ge3b8b4f7814c54, but I only added the preprocessor logic and didn't use ARGS in the code. libstdc++-v3/ChangeLog: * testsuite/26_numerics/random/discrete_distribution/operators/values.cc: Use ARGS to limit number of iterations for simulators.
2024-08-01libstdc++: Constrain std::basic_string default constructor [PR113841]Jonathan Wakely3-0/+36
This is needed to avoid errors outside the immediate context when evaluating is_default_constructible_v<basic_string<C, T, A>> when A is not default constructible. This change is not sufficient to solve the problem because there are a large number of member functions which have a default argument that constructs an allocator. libstdc++-v3/ChangeLog: PR libstdc++/113841 * include/bits/basic_string.h (basic_string::basic_string()): Constrain so that it's only present if the allocator is default constructible. * include/bits/cow_string.h (basic_string::basic_string()): Likewise. * testsuite/21_strings/basic_string/cons/113841.cc: New test.
generated by cgit v1.1 at 2025-02-08 12:51:28 +0000