aboutsummaryrefslogtreecommitdiff
path: root/libstdc++-v3
AgeCommit message (Collapse)AuthorFilesLines
2025-03-13libstdc++: Implement <stdckdint.h> for C++26 (P3370R1)Jonathan Wakely6-0/+225
This is the second part of the P3370R1 proposal just approved by the committee in Wrocław. This adds C++ equivalents of the functions added to C23 by WG14 N2683. These functions are in the global namespace, but to avoid collisions with the same functions defined by other standard library implementations, this change defines them in namespace __gnu_cxx and then adds them to the global namespace. libstdc++-v3/ChangeLog: * include/Makefile.am: Add stdckdint.h. * include/Makefile.in: Regenerate. * src/c++23/std.compat.cc.in: Export <stdckdint.h> functions. * include/c_compatibility/stdckdint.h: New file. * testsuite/26_numerics/stdckdint/1.cc: New test. * testsuite/26_numerics/stdckdint/2_neg.cc: New test. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-13libstdc++: Implement <stdbit.h> for C++26 (P3370R1)Jonathan Wakely6-0/+978
This is the first part of the P3370R1 proposal just approved by the committee in Wrocław. This adds C++ equivalents of the functions added to C23 by WG14 N3022. These functions are in the global namespace, but to avoid collisions with the same functions defined by other standard library implementations, this change defines them in namespace __gnu_cxx and then adds them to the global namespace. libstdc++-v3/ChangeLog: * include/Makefile.am: Add stdbit.h. * include/Makefile.in: Regenerate. * src/c++23/std.compat.cc.in: Export <stdbit.h> functions. * include/c_compatibility/stdbit.h: New file. * testsuite/20_util/stdbit/1.cc: New test. * testsuite/20_util/stdbit/2_neg.cc: New test. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-13libstdc++: Fix ref_view branch of views::as_const [PR119135]Patrick Palka2-6/+10
Unlike for span<X> and empty_view<X>, the range_reference_t of ref_view<X> doesn't correspond to X. This patch fixes the ref_view branch of views::as_const to correctly query its underlying range type X. PR libstdc++/119135 libstdc++-v3/ChangeLog: * include/std/ranges: Include <utility>. (views::__detail::__is_ref_view): Replace with ... (views::__detail::__is_constable_ref_view): ... this. (views::_AsConst::operator()): Replace bogus use of element_type in the ref_view branch. * testsuite/std/ranges/adaptors/as_const/1.cc (test03): Extend test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-13libstdc++: Allow 'configure.host' to pre-set 'EXTRA_CFLAGS', 'EXTRA_CXX_FLAGS'Thomas Schwinge3-2/+10
In particular, 'GLIBCXX_ENABLE_CXX_FLAGS' shouldn't overwrite 'EXTRA_CXX_FLAGS' (and instead append any additional '--enable-cxx-flags=[...]'). libstdc++-v3/ * acinclude.m4 (GLIBCXX_ENABLE_CXX_FLAGS): Append to 'EXTRA_CXX_FLAGS' any additional flags. * configure: Regenerate. * configure.host: Document 'EXTRA_CFLAGS', 'EXTRA_CXX_FLAGS'.
2025-03-13libstdc++: Hide 128-bit int and float types behind handle for ↵Tomasz Kamiński3-9/+123
basic_format_arg visitation [PR108053] Implement visit_format_arg and basic_format_arg::visit function, in terms of _M_visit_user member functions, that wraps any type stored inside basic_format_arg, that is not specified in the standard, into the handle. This affects __int128, unsigned __int128, PowerPC specific __ieee128 and __ibm128, and _Float128 for architectures where long double is not 128bits. The bfloat16, _Float16, _Float32, _Float32, and _Float128 for 128bits long double are not are not addressed, as they are transformed into a standard floating point types. For internal purposes __format::__visit_format_arg function is used, that provides an unmodified access to stored object. PR libstdc++/108053 libstdc++-v3/ChangeLog: * include/std/format (basic_format_arg::_M_visit_user): Helper function for wrapping extension types into handle. (visit_format_arg): Call `_M_visit_user` instead of `_M_visit`. (basic_format_arg::visit): As above. (__format::__visit_format_arg): Provides direct access to values stored in basic_format_arg. (__format::__int_from_arg): Use __format::__visit_format_arg instead of std::visit_format_arg. (_Formatting_scanner::_M_format_arg): As above. (_Checking_scanner::__do_vformat_to): As above. * testsuite/std/format/arguments/args.cc: New tests. * testsuite/std/format/string.cc: Test for using __int128 as width/precision. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-13Daily bump.GCC Administrator1-0/+89
2025-03-12libstdc++: Implement P3137R3 views::to_input for C++26Patrick Palka4-0/+247
libstdc++-v3/ChangeLog: * include/bits/version.def (ranges_to_input): Define. * include/bits/version.h: Regenerate. * include/std/ranges (ranges::to_input_view): Define for C++26. (views::__detail::__can_to_input): Likewise. (views::_ToInput, views::to_input): Likewise. * testsuite/std/ranges/adaptors/to_input/1.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-12libstdc++: Use new <bits/monostate.h> header in <format>Jonathan Wakely1-1/+1
In r15-5832-g91f4550e1700b7 std::monostate was moved to its own header, which means that <format> no longer needs to include all of <variant>. libstdc++-v3/ChangeLog: * include/std/format: Include <bits/monostate.h> instead of <variant>.
2025-03-12libstdc++: Optimize basic_format_parse_context::check_dynamic_specJonathan Wakely2-54/+62
This change makes the check_dynamic_spec precondition checks slightly faster to compile, and avoids those checks entirely for the common cases of calling check_dynamic_spec_integral or check_dynamic_spec_string. Instead of checking for unique types by keeping counts in an array and looping over that array, we can just keep a sum of how many valid types are present, and check that it equals the total number of types in the pack. The diagnostic is slightly worse now, because there's only a single "invalid template argument types" string that appears in the output, where previously we had either "non-unique template argument type" or "disallowed template argument type", depending on the failure mode. Given that most users will never use this function directly, and probably won't use invalid types anyway, the inferior diagnostic seems acceptable. libstdc++-v3/ChangeLog: * include/std/format (basic_format_parse_context::__once): New variable template. (basic_format_parse_context::__valid_types_for_check_dynamic_spec): New function template for checking argument types. (basic_format_parse_context::__check_dynamic_spec): New function template to implement the common check_dynamic_spec logic. (basic_format_parse_context::check_dynamic_spec_integral): Call __check_dynamic_spec instead of check_dynamic_spec. (basic_format_parse_context::check_dynamic_spec_string): Likewise. Use _CharT instead of char_type consistently. (basic_format_parse_context::check_dynamic_spec): Use __valid_types_for_check_dynamic_spec for precondition checks and call __check_dynamic_spec for checking the arg id. * testsuite/std/format/parse_ctx_neg.cc: Adjust expected errors. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-12libstdc++: Add static_assert to std::packaged_task::packaged_task(F&&)Jonathan Wakely3-1/+47
LWG 4154 (approved in Wrocław, November 2024) fixed the Mandates: precondition for std::packaged_task::packaged_task(F&&) to match what the implementation actually requires. We already gave a diagnostic in the right cases as required by the issue resolution, so strictly speaking we don't need to do anything. But the current diagnostic comes from inside the implementation of std::__invoke_r and could be more user-friendly. For C++17 (when std::is_invocable_r_v is available) add a static_assert to the constructor, so the error is clear: .../include/c++/15.0.1/future: In instantiation of 'std::packaged_task<_Res(_ArgTypes ...)>::packaged_task(_Fn&&) [with _Fn = const F&; <template-parameter-2-2> = void; _Res = void; _ArgTypes = {}]': lwg4154_neg.cc:15:31: required from here 15 | std::packaged_task<void()> p(f); // { dg-error "here" "" { target c++17 } } | ^ .../include/c++/15.0.1/future:1575:25: error: static assertion failed 1575 | static_assert(is_invocable_r_v<_Res, decay_t<_Fn>&, _ArgTypes...>); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Also add a test to confirm we get a diagnostic as the standard requires. libstdc++-v3/ChangeLog: * include/std/future (packaged_task::packaged_task(F&&)): Add static_assert. * testsuite/30_threads/packaged_task/cons/dangling_ref.cc: Add dg-error for new static assertion. * testsuite/30_threads/packaged_task/cons/lwg4154_neg.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-12libstdc++: Update tzdata to 2025aJonathan Wakely3-848/+840
Import the new 2025a tzdata.zi file. The leapseconds file was also updated to have a new expiry (no new leap seconds were added). libstdc++-v3/ChangeLog: * include/std/chrono (__detail::__get_leap_second_info): Update expiry date for leap seconds list. * src/c++20/tzdata.zi: Import new file from 2025a release. * src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds) Update expiry date for leap seconds list.
2025-03-12libstdc++: Correct preprocessing checks for floatX_t and bfloat_16 formattingTomasz Kamiński1-24/+8
Floating points types _Float16, _Float32, _Float64, and bfloat16, can be formatted only if std::to_chars overloads for such types were provided. Currently this is only the case for architectures where float and double are 32-bits and 64-bits IEEE floating points types. This patch updates the preprocessing checks for formatters for above types to check _GLIBCXX_FLOAT_IS_IEEE_BINARY32 and _GLIBCXX_DOUBLE_IS_IEEE_BINARY64. Making them non-formattable on non-IEEE architectures. Remove a potential UB, where we could produce basic_format_arg with _M_type set to _Arg_fp32 or _Arg_fp64, that was later not handled by `_M_visit`. libstdc++-v3/ChangeLog: * include/std/format (formatter<_Float16, _CharT>): Define only if _GLIBCXX_FLOAT_IS_IEEE_BINARY32 macro is defined. (formatter<_Float16, _CharT>): As above. (formatter<__gnu_cxx::__bfloat16_t, _CharT>): As above. (formatter<_Float64, _CharT>): Define only if _GLIBCXX_DOUBLE_IS_IEEE_BINARY64 is defined. (basic_format_arg::_S_to_arg_type): Normalize _Float32 and _Float64 only to float and double respectivelly. (basic_format_arg::_S_to_enum): Remove handling of _Float32 and _Float64. Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-12libstdc++: Add lambda example to case transformation docsJonathan Wakely2-9/+29
libstdc++-v3/ChangeLog: * doc/xml/manual/strings.xml: Tweak formatting. Add example using lambda. * doc/html/manual/strings.html: Regenerate.
2025-03-12libstdc++: Prevent dangling references in std::unique_ptr::operator*Jonathan Wakely2-0/+39
LWG 4148 (approved in Wrocław, November 2024) makes it ill-formed to dereference a std::unique_ptr if that would return a dangling reference. That can happen with a custom pointer type and a const-qualified element_type, such that std::add_lvalue_reference_t<element_type> is a reference-to-const that could bind to a short-lived temporary. In C++26 the compiler diagnoses this as an error anyway: bits/unique_ptr.h:457:16: error: returning reference to temporary [-Wreturn-local-addr] But that can be disabled with -Wno-return-local-addr so the static_assert ensures it is enforced consistently. libstdc++-v3/ChangeLog: * include/bits/unique_ptr.h (unique_ptr::operator*): Add static_assert to check for dangling reference, as per LWG 4148. * testsuite/20_util/unique_ptr/lwg4148.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-12libstdc++: Make range adaptor __has_arrow helper use a const typeJonathan Wakely2-1/+45
LWG 4112 (approved in Wrocław, November 2024) changes the has-arrow helper to require operator-> to be valid on a const-qualified lvalue. This affects the constraints for filter_view::_Iterator::operator-> and join_view::_Iterator::operator-> so that they can only be used if the underlying iterator supports operator-> on const. The change also adds semantic (i.e. not checkable and not enforced) requirements that operator-> must have the same semantics whether called on a const or non-const value, and on an lvalue or rvalue (due to the implicit expression variation rules in [concepts.equality]). libstdc++-v3/ChangeLog: * include/bits/ranges_util.h (ranges::_detail::__has_arrow): Require operator->() to be valid on const-qualified type, as per LWG 4112. * testsuite/std/ranges/adaptors/lwg4112.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-12libstdc++: Reject basic_format_parse_context::check_dynamic_spec<>(n)Jonathan Wakely3-3/+9
LWG 4142 (approved in Wrocław, November 2024) made it ill-formed to call basic_format_parse_context::check_dynamic_spec with an empty template argument list. This adds a static_assert to enforce that, and adjusts the tests. libstdc++-v3/ChangeLog: * include/std/format (basic_format_parse_context::check_dynamic_spec): Require a non-empty parameter pack, as per LWG 4142. * testsuite/std/format/parse_ctx.cc: Remove call of check_dynamic_spec with empty template argument list. * testsuite/std/format/parse_ctx_neg.cc: Add dg-error to call of check_dynamic_spec with empty template argument list. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-09Daily bump.GCC Administrator1-0/+28
2025-03-08libstdc++: constrain std::atomic's default constructorGiuseppe D'Angelo5-11/+57
This commit implements the proposed resolution to LWG4169, which is to constrain std::atomic<T>'s default constructor based on whether T itself is default constructible. At the moment, std::atomic<T>'s primary template in libstdc++ has a defaulted default constructor. Value-initialization of the T member (since C++20 / P0883R2) is done via a NSDMI (= T()). GCC already considers the defaulted constructor constrained/deleted, however this behavior is non-standard (see the discussion in PR116769): the presence of a NSDMI should not make the constructor unavailable to overload resolution/deleted ([class.default.ctor]/2.5 does not apply). When using libstdc++ on Clang, this causes build issues as the constructor is *not* deleted there -- the interpretation of [class.default.ctor]/4 seems to match Clang's behavior. Therefore, although there would be "nothing to do" with GCC+libstdc++, this commit changes the code as to stop relying on the GCC language extension. In C++ >= 20 modes, std::atomic's defaulted default constructor is changed to be a non-defaulted one, with a constraint added as per LWG4169; value-initialization of the data member is moved from the NSDMI to the member init list. The new signature matches the one in the Standard as per [atomics.types.operations]/1. In pre-C++20 modes, the constructor is left defaulted. This ensures compatibility with C++11/14/17 behavior. In other words: we are not backporting P0883R2 to earlier language modes here. Amend an existing test to check that a std::atomic wrapping a non-default constructible type is always non-default constructible: from C++20, because of the constraint; before C++20, because we are removing the NSDMI, and therefore [class.default.ctor]/2.5 applies. Add another test that checks that std::atomic is trivially default constructible in pre-C++20 modes, and it isn't afterwards. libstdc++-v3/ChangeLog: * include/bits/version.def (atomic_value_initialization): Guard the FTM with the language concepts FTM. * include/bits/version.h: Regenerate. * include/std/atomic (atomic): When atomic value init is defined, change the defaulted default constructor to a non-defaulted one, constraining it as per LWG4169. Otherwise, keep the existing constructor. Remove the NSDMI for the _M_i member. (_GLIBCXX20_INIT): Drop the macro, as it is not needed any more. * testsuite/29_atomics/atomic/69301.cc: Test that an atomic wrapping a non-default-constructible type is always itself non-default-constructible (in all language modes). * testsuite/29_atomics/atomic/cons/trivial.cc: New test.
2025-03-08libstdc++: Simplify __memcpyable_iterators conceptJonathan Wakely4-25/+276
My P3349R1 paper clarifies that we should be able to lower contiguous iterators to pointers, without worrying about side effects of individual increment or dereference operations. We do need to advance the iterators, and we need to use std::to_address on the result of advancing them. This ensures that iterators with error detection get a chance to diagnose bugs. If we don't use std::to_address on the advanced iterator, it would be possible for a memcpy on the pointers to overflow a buffer. By performing the += or -= operations and also using std::to_address, we give the iterator a chance to abort, throw, or call a violation handler before the buffer overflow happens. The new tests only check the std::copy* algorithms, because std::move and std::move_backward use the same implementation details. libstdc++-v3/ChangeLog: * include/bits/stl_algobase.h (__nothrow_contiguous_iterator): Remove. (__memcpyable_iterators): Simplify. (__copy_move_a2, __copy_n_a, __copy_move_backward_a2): Call std::to_address on the iterators after advancing them. * testsuite/25_algorithms/copy/contiguous.cc: New test. * testsuite/25_algorithms/copy_backward/contiguous.cc: New test. * testsuite/25_algorithms/copy_n/contiguous.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-08Daily bump.GCC Administrator1-0/+20
2025-03-07libstdc++: Make std::erase for linked lists convert to boolJonathan Wakely4-4/+50
LWG 4135 (approved in Wrocław, November 2024) fixes the lambda expressions used by std::erase for std::list and std::forward_list. Previously they attempted to copy something that isn't required to be copyable. Instead they should convert it to bool right away. The issue resolution also changes the lambda's parameter to be const, so that it can't modify the elements while comparing them. libstdc++-v3/ChangeLog: * include/std/forward_list (erase): Change lambda to have explicit return type and const parameter type. * include/std/list (erase): Likewise. * testsuite/23_containers/forward_list/erasure.cc: Check lambda is correct. * testsuite/23_containers/list/erasure.cc: Likewise. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-07libstdc++: Add poison pill for chrono::from_streamJonathan Wakely1-0/+4
LWG 3956 (approved in Hagenberg, February 2025) decided that from_stream should be found *only* by ADL, not ordinary unqualified lookup. Add a poison pill overload to chrono::__detail where the __parsable concept and operator>>(basic_istream&, _Parser) are defined. This ensures that when they use from_stream unqualified ordinary lookup finds the poison pill, which is deleted, so a usable overload resolution result can only be found by ADL. We already have the std/time/parse/parse.cc test checking that ADL works, so this doesn't add a new test. libstdc++-v3/ChangeLog: * include/bits/chrono_io.h (chrono::__detail::from_stream): Add deleted function as poison pill for unqualified lookup. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-07libstdc++: Add missing static_assert to std::expected<void,E>::value()&&Jonathan Wakely2-0/+70
The r15-2326-gea435261ad58ea change missed a static_assert for is_move_constructible_v in expected<cv void, E>::value()&&. When exceptions are enabled, the program is ill-formed if the error type is not move constructible, because we can't construct the std::bad_expected_access. But prior to r15-7856-gd87c0d5443ba86, using -fno-exceptions meant that we never constructed an exception, so didn't need to copy/move the error value. So that we don't rely on the r15-7856-gd87c0d5443ba86 change to the _GLIBCXX_THROW_OR_ABORT macro to consistently enforce the Mandates: conditions whether exceptions are enabled or not, we should check the requirement explicitly. This adds the missing static_assert. It also adds a test that verifies the Mandates: conditions added by LWG 3843 and 3490 are enforced even with -fno-exceptions. libstdc++-v3/ChangeLog: * include/std/expected (expected<cv void,E>::value()&&): Add missing static_assert for LWG 3940. * testsuite/20_util/expected/lwg3843.cc: New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
2025-03-07Daily bump.GCC Administrator1-0/+88
2025-03-06libstdc++: Make std::unique_lock self-move-assignableJonathan Wakely4-7/+59
LWG 4172 was approved in Hagenberg, February 2025, fixing std::unique_lock and std::shared_lock to work correctly for self-move-assignment. Our std::shared_lock was already doing the right thing (contradicting the standard) so just add a comment there. Our std::unique_lock needs to be fixed to do the right thing. libstdc++-v3/ChangeLog: * include/bits/unique_lock.h (unique_lock::operator=): Fix for self-move-assignment. * include/std/shared_mutex (shared_lock::operator=): Add comment. * testsuite/30_threads/shared_lock/cons/lwg4172.cc: New test. * testsuite/30_threads/unique_lock/cons/lwg4172.cc: New test. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-06libstdc++: Add assertions to std::list::pop_{front,back}Jonathan Wakely1-2/+8
The recently-approved Standard Library Hardening proposal (P3471R4) gives pop_front and pop_back member functions hardened preconditions, but std::list was missing assertions on them. Our other sequence containers do have assertions on those members. libstdc++-v3/ChangeLog: * include/bits/stl_list.h (list::pop_front, list::pop_back): Add non-empty assertions. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-06libstdc++: Ensure <bits/ranges_util.h> defines __pair_likeJonathan Wakely1-0/+3
We need to include <bits/stl_pair.h> in C++23 and later, so that __pair_like_convertible_from can use __pair_like, and so that __is_tuple_like_v is declared before we define a partial specialization. libstdc++-v3/ChangeLog: * include/bits/ranges_util.h: Include <bits/stl_pair.h>. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-06libstdc++: Remove redundant std::span destructorJonathan Wakely1-2/+0
This destructor declaration serves no purpose, as pointed out by LWG 3903 which was approved at Varna, June 2023. libstdc++-v3/ChangeLog: * include/std/span (span::~span): Remove, as per LWG 3903. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-06libstdc++: Fix failures in new std::complex test [PR119144]Jonathan Wakely1-4/+5
This test fails due to duplicate explicit instantiations on targets where size_t and unsigned int are the same type. It also fails with -D_GLIBCXX_USE_CXX11_ABI=0 due to using std::string in constexpr functions, and with --disable-libstdcxx-pch due to not including <algorithm> for ranges::fold_left. libstdc++-v3/ChangeLog: PR libstdc++/119144 * testsuite/26_numerics/complex/tuple_like.cc: Include <algorithm>, replace std::string with std::string_view, instantiate tests for long instead of size_t.
2025-03-06Fix 'libstdc++-v3/src/c++20/tzdb.cc' build for '__GTHREADS && ↵Jonathan Wakely1-1/+11
!__GTHREADS_CXX0X' configurations libstdc++-v3/ * src/c++20/tzdb.cc [__GTHREADS && !__GTHREADS_CXX0X]: Use '__gnu_cxx::__mutex'. Co-authored-by: Thomas Schwinge <tschwinge@baylibre.com>
2025-03-06libstdc++: Avoid '-Wunused-parameter' for 'out' in member function ↵Thomas Schwinge1-1/+1
'std::codecvt_base::result std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&) const' In a newlib configuration: ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc: In member function ‘std::codecvt_base::result std::__format::{anonymous}::__encoding::conv(std::string_view, std::string&) const’: ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:100:35: error: unused parameter ‘out’ [-Werror=unused-parameter] 100 | conv(string_view input, string& out) const | ~~~~~~~~^~~ libstdc++-v3/ * src/c++20/format.cc (conv): Tag 'out' as '[[maybe_unused]]'.
2025-03-06libstdc++: Avoid '-Wunused-parameter' for 'is_directory' in member function ↵Thomas Schwinge1-1/+1
'bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_code&) const' In a newlib configuration: ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc: In member function ‘bool std::filesystem::__cxx11::_Dir::do_unlink(bool, std::error_code&) const’: ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:147:18: error: unused parameter ‘is_directory’ [-Werror=unused-parameter] 147 | do_unlink(bool is_directory, error_code& ec) const noexcept | ~~~~~^~~~~~~~~~~~ libstdc++-v3/ * src/c++17/fs_dir.cc (do_unlink): Tag 'is_directory' as '[[maybe_unused]]'.
2025-03-06libstdc++: Avoid '-Wunused-parameter' for 'nofollow' in static member ↵Thomas Schwinge1-1/+1
function 'static std::filesystem::__gnu_posix::DIR* std::filesystem::_Dir_base::openat(const _At_path&, bool)' In a newlib configuration: In file included from ../../../../../source-gcc/libstdc++-v3/src/c++17/fs_dir.cc:37, from ../../../../../source-gcc/libstdc++-v3/src/c++17/cow-fs_dir.cc:26: ../../../../../source-gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h: In static member function ‘static std::filesystem::__gnu_posix::DIR* std::filesystem::_Dir_base::openat(const _At_path&, bool)’: ../../../../../source-gcc/libstdc++-v3/src/c++17/../filesystem/dir-common.h:210:36: error: unused parameter ‘nofollow’ [-Werror=unused-parameter] 210 | openat(const _At_path& atp, bool nofollow) | ~~~~~^~~~~~~~ libstdc++-v3/ * src/filesystem/dir-common.h (openat): Tag 'nofollow' as '[[maybe_unused]]'.
2025-03-06libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void ↵Thomas Schwinge1-1/+1
std::__throw_format_error(const char*)' In a '-fno-exceptions' configuration: In file included from ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29: [...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void std::__throw_format_error(const char*)’: [...]/build-gcc/[...]/libstdc++-v3/include/format:200:36: error: unused parameter ‘__what’ [-Werror=unused-parameter] 200 | __throw_format_error(const char* __what) | ~~~~~~~~~~~~^~~~~~ libstdc++-v3/ * include/bits/c++config [!__cpp_exceptions] (_GLIBCXX_THROW_OR_ABORT): Reference '_EXC'. Co-authored-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-06libstdc++: Fix constexpr memory algo tests for COW std::stringJonathan Wakely5-0/+10
The old COW std::string is not usable in constant expressions, so these new tests fail with -D_GLIBCXX_USE_CXX11_ABI=0. The parts of the tests using std::string can be conditionally skipped. libstdc++-v3/ChangeLog: * testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc: Do not test COW std::string in constexpr contexts. * testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc: Likewise. * testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc: Likewise. * testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc: Likewise. * testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc: Likewise. Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
2025-03-06libstdc++: implement tuple protocol for std::complex (P2819R2)Giuseppe D'Angelo6-1/+316
This commit implements P2819R2 for C++26, making std::complex destructurable and tuple-like (see [complex.tuple]). std::get needs to get forward declared in stl_pair.h (following the existing precedent for the implementation of P2165R4, cf. r14-8710-g65b4cba9d6a9ff), and implemented in <complex>. Also, std::get(complex<T>) needs to return *references* to the real and imaginary parts of a std::complex object, honoring the value category and constness of the argument. In principle a straightforward task, it gets a bit convoluted by the fact that: 1) std::complex does not have existing getters that one can use for this (real() and imag() return values, not references); 2) there are specializations for language/extended floating-point types, which requires some duplication -- need to amend the primary and all the specializations; 3) these specializations use a `__complex__ T`, but the primary template uses two non-static data members, making generic code harder to write. The implementation choice used here is to add the overloads of std::get for complex as declared in [complex.tuple]. In turn they dispatch to a newly added getter that extracts references to the real/imaginary parts of a complex<T>. This getter is private API, and the implementation depends on whether it's the primary (bind the data member) or a specialization (use the GCC language extensions for __complex__). To avoid duplication and minimize template instantiations, the getter uses C++23's deducing this (this avoids const overloads). The value category is dealt with by the std::get overloads. Add a test that covers the aspects of the tuple protocol, as well as the tuple-like interface. While at it, add a test for the existing tuple-like feature-testing macro. PR libstdc++/113310 libstdc++-v3/ChangeLog: * include/bits/stl_pair.h (get): Forward-declare std::get for std::complex. * include/bits/version.def (tuple_like): Bump the value of the feature-testing macro in C++26. * include/bits/version.h: Regenerate. * include/std/complex: Implement the tuple protocol for std::complex. (tuple_size): Specialize for std::complex. (tuple_element): Ditto. (__is_tuple_like_v): Ditto. (complex): Add a private getter to obtain references to the real and the imaginary part, on the primary class template and on its specializations. (get): Add overloads of std::get for std::complex. * testsuite/20_util/tuple/tuple_like_ftm.cc: New test. * testsuite/26_numerics/complex/tuple_like.cc: New test.
2025-03-06Daily bump.GCC Administrator1-0/+90
2025-03-05libstdc++: Make enumerate_view::iterator::operator- noexceptJonathan Wakely2-1/+12
Implement LWG 3912, approved in Varna, June 2023. libstdc++-v3/ChangeLog: * include/std/ranges (enumerate_view::_Iterator::operator-): Add noexcept, as per LWG 3912. * testsuite/std/ranges/adaptors/enumerate/1.cc: Check iterator difference is noexcept.
2025-03-05libstdc++: fix possible undefined std::timespec in module stdyxj-github-4371-1/+1
I notice std::timespec and std::timespec_get are used in preprocessor condition _GLIBCXX_HAVE_TIMESPEC_GET. So in module std, it should be the same. libstdc++-v3: * src/c++23/std-clib.cc.in (timespec): Move within preprocessor group guarded by _GLIBCXX_HAVE_TIMESPEC_GET.
2025-03-05libstdc++: Move new functions to separate files [PR119110]Jonathan Wakely4-58/+66
The new test functions I added in r15-7765-g3866ca796d5281 are causing those tests to FAIL on Solaris and arm-thumb due to the linker complaining about undefined functions. The new test functions are not called, so it shouldn't matter that they call undefined member functions, but it does. Move those functions to separate { dg-do compile } files so the linker isn't used and won't complain. libstdc++-v3/ChangeLog: PR libstdc++/119110 * testsuite/25_algorithms/move/constrained.cc: Move test06 function to ... * testsuite/25_algorithms/move/105609.cc: New test. * testsuite/25_algorithms/move_backward/constrained.cc: Move test04 function to ... * testsuite/25_algorithms/move_backward/105609.cc: New test.
2025-03-05libstdc++: Implement P3138R5 views::cache_latestPatrick Palka4-0/+279
libstdc++-v3/ChangeLog: * include/bits/version.def (ranges_cache_latest): Define. * include/bits/version.h: Regenerate. * include/std/ranges (__detail::__non_propagating_cache::_M_reset): Export from base class _Optional_base. (cache_latest_view): Define for C++26. (cache_latest_view::_Iterator): Likewise. (cache_latest_view::_Sentinel): Likewise. (views::__detail::__can_cache_latest): Likewise. (views::_CacheLatest, views::cache_latest): Likewise. * testsuite/std/ranges/adaptors/cache_latest/1.cc: New test. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-05libstdc++: use if consteval in stable_sortGiuseppe D'Angelo1-5/+5
This is a C++ >= 26 codepath for supporting constexpr stable_sort, so we know that we have if consteval available; it just needs protection with the feature-testing macro. Also merge the return in the same statement. Amends r15-7708-gff43f9853d3b10. libstdc++-v3/ChangeLog: * include/bits/stl_algo.h (__stable_sort): Use if consteval instead of is_constant_evaluated. Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-05libstdc++: Some concat_view bugfixes [PR115215, PR115218, LWG 4082]Patrick Palka2-12/+29
- Use __builtin_unreachable to suppress a false-positive "control reaches end of non-void function" warning in the recursive lambda (which the existing tests failed to notice since test01 wasn't being called at runtime) - Relax the constraints on views::concat in the single-argument case as per PR115215 - Add an input_range requirement to that same case as per LWG 4082 - In the const-converting constructor of concat_view's iterator, don't require the first iterator to be default constructible PR libstdc++/115215 PR libstdc++/115218 libstdc++-v3/ChangeLog: * include/std/ranges (concat_view::iterator::_S_invoke_with_runtime_index): Use __builtin_unreachable in recursive lambda to certify it always exits via 'return'. (concat_view::iterator::iterator): In the const-converting constructor, direct initialize _M_it. (views::_Concat::operator()): Adjust constraints in the single-argument case as per LWG 4082. * testsuite/std/ranges/concat/1.cc (test01): Call it at runtime too. (test04): New test. Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-05libstdc++: Fix subrange conversion to pair-like [PR119121]Tomasz Kamiński2-1/+30
Fix regression introduced by r14-8710-g65b4cba9d6a9ff PR libstdc++/119121 libstdc++-v3/ChangeLog: * include/bits/ranges_util.h (__detail::__pair_like_convertible_from): Use `_Tp` in `is_reference_v` check * testsuite/std/ranges/subrange/tuple_like.cc: New tests for pair-like conversion Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
2025-03-05libstdc++: implement constexpr memory algorithmsGiuseppe D'Angelo12-1/+406
This commit adds support for C++26's constexpr specialized memory algorithms, introduced by P2283R2, P3508R0, P3369R0. The uninitialized_default, value, copy, move and fill algorithms are affected, in all of their variants (iterator-based, range-based and _n versions.) The changes are mostly mechanical -- add `constexpr` to a number of signatures when compiling in C++26 and above modes. The internal helper guard class for range algorithms instead can be marked unconditionally. uninitialized_default_construct is implemented in terms of the _Construct_novalue helper, which requires support for C++26's constexpr placement new from the compiler (P2747R2, which GCC implements). We can simply mark it as constexpr in C++26 language modes, even if the compiler does not support P2747R2 (e.g. Clang 17/18), because C++23's P2448R2 makes it OK to mark functions as constexpr even if they never qualify, and other compilers implement this. The only "real" change to the implementation of the algorithms is that during constant evaluation I need to dispatch to a constexpr-friendly version of them. For each algorithm family I've added only one test to cover it and its variants; the idea is to avoid too much repetition and simplify future maintenance. libstdc++-v3/ChangeLog: * include/bits/ranges_uninitialized.h: Mark the specialized memory algorithms as constexpr in C++26. Also mark the members of the _DestroyGuard helper class. * include/bits/stl_uninitialized.h: Ditto. * include/bits/stl_construct.h: (_Construct_novalue) Mark it as constexpr in C++26. * include/bits/version.def (raw_memory_algorithms): Bump the feature-testing macro for C++26. * include/bits/version.h: Regenerate. * testsuite/20_util/headers/memory/synopsis.cc: Add constexpr to the uninitialized_* algorithms (when in C++26) in the test. * testsuite/20_util/specialized_algorithms/feature_test_macro.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc: New test. * testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc: New test. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-03-05Daily bump.GCC Administrator1-0/+5
2025-03-04libstdc++: Remove stray comma in testing docsJonathan Wakely2-2/+2
libstdc++-v3/ChangeLog: * doc/xml/manual/test.xml: Remove stray comma. * doc/html/manual/test.html: Regenerate.
2025-03-01Daily bump.GCC Administrator1-0/+56
2025-02-28libstdc++: Fix ranges::iter_move handling of rvalues [PR106612]Jonathan Wakely2-9/+119
The specification for std::ranges::iter_move apparently requires us to handle types which do not satisfy std::indirectly_readable, for example with overloaded operator* which behaves differently for different value categories. libstdc++-v3/ChangeLog: PR libstdc++/106612 * include/bits/iterator_concepts.h (_IterMove::__iter_ref_t): New alias template. (_IterMove::__result): Use __iter_ref_t instead of std::iter_reference_t. (_IterMove::__type): Remove incorrect __dereferenceable constraint. (_IterMove::operator()): Likewise. Add correct constraints. Use __iter_ref_t instead of std::iter_reference_t. Forward parameter as correct value category. (iter_swap): Add comments. * testsuite/24_iterators/customization_points/iter_move.cc: Test that iter_move is found by ADL and that rvalue arguments are handled correctly. Reviewed-by: Patrick Palka <ppalka@redhat.com>
2025-02-28libstdc++: Fix ranges::move and ranges::move_backward to use iter_move ↵Jonathan Wakely3-6/+78
[PR105609] The ranges::move and ranges::move_backward algorithms are supposed to use ranges::iter_move(iter) instead of std::move(*iter), which matters for an iterator type with an iter_move overload findable by ADL. Currently those algorithms use std::__assign_one which uses std::move, so define a new ranges::__detail::__assign_one helper function that uses ranges::iter_move. libstdc++-v3/ChangeLog: PR libstdc++/105609 * include/bits/ranges_algobase.h (__detail::__assign_one): New helper function. (__copy_or_move, __copy_or_move_backward): Use new function instead of std::__assign_one. * testsuite/25_algorithms/move/constrained.cc: Check that ADL iter_move is used in preference to std::move. * testsuite/25_algorithms/move_backward/constrained.cc: Likewise.