- Feb 28, 2025
-
-
Jonathan Wakely authored
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>
-
Jonathan Wakely authored
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.
-
Jonathan Wakely authored
The standard requires that we reject attempts to create a ranges::to adaptor for cv-qualified types and non-class types. Currently we only diagnose it once the adaptor is used in a pipeline. This adds static assertions to diagnose it immediately. libstdc++-v3/ChangeLog: PR libstdc++/112803 * include/std/ranges (ranges::to): Add static assertions to enforce Mandates conditions. * testsuite/std/ranges/conv/112803.cc: New test.
-
Patrick Palka authored
Here for using RCI = reverse_iterator<basic_const_iterator<vector<int>::iterator>> static_assert(std::totally_ordered<RCI>); we effectively need to check the requirement requires (RCI x) { x RELOP x; } for each RELOP in {<, >, <=, >=} which we expect to be straightforwardly satisfied by reverse_iterator's namespace-scope relops. But due to ADL we find ourselves also considering the basic_const_iterator relop friends, which before CWG 2369 would be quickly discarded since RCI clearly isn't convertible to basic_const_iterator. After CWG 2369 though we must first check these relops' constraints (with _It = vector<int>::iterator and _It2 = RCI), which entails checking totally_ordered<RCI> recursively. This patch fixes this by turning the problematic non-dependent function parameters of type basic_const_iterator<_It> into dependent ones of type basic_const_iterator<_It3> where _It3 is constrained to match _It. Thus the basic_const_iterator relop friends now get quickly discarded during deduction and before the constraint check if the second operand isn't a specialization of basic_const_iterator (or derived from one) like before CWG 2369. PR libstdc++/112490 libstdc++-v3/ChangeLog: * include/bits/stl_iterator.h (basic_const_iterator::operator<): Replace non-dependent basic_const_iterator function parameter with a dependent one of type basic_const_iterator<_It3> where _It3 matches _It. (basic_const_iterator::operator>): Likewise. (basic_const_iterator::operator<=): Likewise. (basic_const_iterator::operator>=): Likewise. * testsuite/24_iterators/const_iterator/112490.cc: New test. Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
- Feb 25, 2025
-
-
Giuseppe D'Angelo authored
stable_sort has been made constexpr in C++26. Apart from plastering a few functions with constexpr, there's an implementation challenge, that is: stable_sort takes different codepaths in case extra memory can be allocated. Rather than doing some major refactorings, simply use the non-allocating path during constant evaluation. That's the same codepath used when extra memory could not be allocated, as well as by freestanding. libstdc++-v3/ChangeLog: * include/bits/algorithmfwd.h (stable_sort): Add constexpr. * include/bits/ranges_algo.h (__stable_sort_fn): Add constexpr to the function call operators. * include/bits/stl_algo.h (__stable_sort): Add constexpr. During constant evaluation, always use the non-allocating path. (stable_sort): Add constexpr. (__inplace_stable_sort): Likewise. (__merge_without_buffer): Likewise. * include/bits/version.def (constexpr_algorithms): Bump value for C++26. * include/bits/version.h: Regnerate. * testsuite/25_algorithms/cpp_lib_constexpr.cc: Test the bumped feature-testing macro. * testsuite/25_algorithms/headers/algorithm/synopsis.cc: Adapt the test to constexpr stable_sort. * testsuite/25_algorithms/stable_sort/constexpr.cc: New test. Signed-off-by:
Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
-
François Dumont authored
It is wrong to reuse a cached hash code from another container when this code depends on the state of the container's Hash functor. Add checks that Hash functor is stateless before reusing the cached hash code. libstdc++-v3/ChangeLog: * include/bits/hashtable_policy.h (_Hash_code_base::_M_copy_code, _Hash_code_base::_M_store_code): Remove. * include/bits/hashtable.h (_M_hash_code_ext): New. (_M_merge_multi(_Hashtable&)): Use latter. (_M_copy_code): New. (_M_assign): Use latter. (_M_bucket_index_ex): New. (_M_equals): Use latter. (_M_store_code): New. (_M_src_hash_code): Remove key_type parameter. * testsuite/23_containers/unordered_map/modifiers/merge.cc (test10): New test case.
-
Patrick Palka authored
LWG 4027 effectively makes the const range access CPOs ranges::cfoo behave more consistently across C++23 and C++20 (pre-P2278R4) and also more consistently with the std::cfoo range accessors, as the below testcase adjustments demonstrate (which mostly consist of reverting workarounds added by r14-3771-gf12e26f3496275 and r13-7186-g0d94c6df183375). In passing fix PR118083 which reports that the input_range constraint on possibly-const-range is missing in our implementation. A consequence of this is that the const range access CPOs now consistently reject a non-range argument, and so in some our of tests we need to introduce otherwise unused begin/end members. PR libstdc++/118083 libstdc++-v3/ChangeLog: * include/bits/ranges_base.h (ranges::__access::__possibly_const_range): Adjust logic as per LWG 4027. Add missing input_range constraint. * testsuite/std/ranges/access/cbegin.cc (test05): Verify LWG 4027 testcases. * testsuite/std/ranges/access/cdata.cc: Adjust, simplify and consolidate some tests after the above. * testsuite/std/ranges/access/cend.cc: Likewise. * testsuite/std/ranges/access/crbegin.cc: Likewise. * testsuite/std/ranges/access/crend.cc: Likewise. * testsuite/std/ranges/adaptors/join.cc: Likewise. * testsuite/std/ranges/adaptors/take_while.cc: Likewise. * testsuite/std/ranges/adaptors/transform.cc: Likewise. Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
- Feb 22, 2025
-
-
Thomas Schwinge authored
Turn test cases into UNSUPPORTED if running into 'sorry, unimplemented: dynamic stack allocation not supported' In Subversion r217296 (Git commit e2acc079) "Testsuite alloca fixes for ptx", effective-target 'alloca' was added to mark up test cases that run into the nvptx back end's non-support of dynamic stack allocation. (Later, nvptx gained conditional support for that in commit 3861d362 "nvptx: PTX 'alloca' for '-mptx=7.3'+, '-march=sm_52'+ [PR65181]", but on the other hand, in commit f93a612f "bpf: liberate R9 for general register allocation", the BPF back end joined "the list of targets that do not support alloca in target-support.exp". Manually maintaining the list of test cases requiring effective-target 'alloca' is notoriously hard, gets out of date quickly: new test cases added to the test suite may need to be analyzed and annotated, and over time annotations also may need to be removed, in cases where the compiler learns to optimize out 'alloca'/VLA usage, for example. This commit replaces (99 % of) the manual annotations with an automatic scheme: turn test cases into UNSUPPORTED if running into 'sorry, unimplemented: dynamic stack allocation not supported'. gcc/testsuite/ * lib/target-supports.exp (check_effective_target_alloca): Gracefully handle the case that we've not be called (indirectly) from 'dg-test'. * lib/gcc-dg.exp (proc gcc-dg-prune): Turn 'sorry, unimplemented: dynamic stack allocation not supported' into UNSUPPORTED. * c-c++-common/Walloca-larger-than.c: Don't 'dg-require-effective-target alloca'. * c-c++-common/Warray-bounds-9.c: Likewise. * c-c++-common/Warray-bounds.c: Likewise. * c-c++-common/Wdangling-pointer-2.c: Likewise. * c-c++-common/Wdangling-pointer-4.c: Likewise. * c-c++-common/Wdangling-pointer-5.c: Likewise. * c-c++-common/Wdangling-pointer.c: Likewise. * c-c++-common/Wimplicit-fallthrough-7.c: Likewise. * c-c++-common/Wsizeof-pointer-memaccess1.c: Likewise. * c-c++-common/Wsizeof-pointer-memaccess2.c: Likewise. * c-c++-common/Wstringop-truncation.c: Likewise. * c-c++-common/Wunused-var-6.c: Likewise. * c-c++-common/Wunused-var-8.c: Likewise. * c-c++-common/analyzer/alloca-leak.c: Likewise. * c-c++-common/analyzer/allocation-size-multiline-2.c: Likewise. * c-c++-common/analyzer/allocation-size-multiline-3.c: Likewise. * c-c++-common/analyzer/capacity-1.c: Likewise. * c-c++-common/analyzer/capacity-3.c: Likewise. * c-c++-common/analyzer/imprecise-floating-point-1.c: Likewise. * c-c++-common/analyzer/infinite-recursion-alloca.c: Likewise. * c-c++-common/analyzer/malloc-callbacks.c: Likewise. * c-c++-common/analyzer/malloc-paths-8.c: Likewise. * c-c++-common/analyzer/out-of-bounds-5.c: Likewise. * c-c++-common/analyzer/out-of-bounds-diagram-11.c: Likewise. * c-c++-common/analyzer/uninit-alloca.c: Likewise. * c-c++-common/analyzer/write-to-string-literal-5.c: Likewise. * c-c++-common/asan/alloca_loop_unpoisoning.c: Likewise. * c-c++-common/auto-init-11.c: Likewise. * c-c++-common/auto-init-12.c: Likewise. * c-c++-common/auto-init-15.c: Likewise. * c-c++-common/auto-init-16.c: Likewise. * c-c++-common/builtins.c: Likewise. * c-c++-common/dwarf2/vla1.c: Likewise. * c-c++-common/gomp/pr61486-2.c: Likewise. * c-c++-common/torture/builtin-clear-padding-4.c: Likewise. * c-c++-common/torture/strub-run3.c: Likewise. * c-c++-common/torture/strub-run4.c: Likewise. * c-c++-common/torture/strub-run4c.c: Likewise. * c-c++-common/torture/strub-run4d.c: Likewise. * c-c++-common/torture/strub-run4i.c: Likewise. * g++.dg/Walloca1.C: Likewise. * g++.dg/Walloca2.C: Likewise. * g++.dg/cpp0x/pr70338.C: Likewise. * g++.dg/cpp1y/lambda-generic-vla1.C: Likewise. * g++.dg/cpp1y/vla10.C: Likewise. * g++.dg/cpp1y/vla2.C: Likewise. * g++.dg/cpp1y/vla6.C: Likewise. * g++.dg/cpp1y/vla8.C: Likewise. * g++.dg/debug/debug5.C: Likewise. * g++.dg/debug/debug6.C: Likewise. * g++.dg/debug/pr54828.C: Likewise. * g++.dg/diagnostic/pr70105.C: Likewise. * g++.dg/eh/cleanup5.C: Likewise. * g++.dg/eh/spbp.C: Likewise. * g++.dg/ext/builtin_alloca.C: Likewise. * g++.dg/ext/tmplattr9.C: Likewise. * g++.dg/ext/vla10.C: Likewise. * g++.dg/ext/vla11.C: Likewise. * g++.dg/ext/vla12.C: Likewise. * g++.dg/ext/vla15.C: Likewise. * g++.dg/ext/vla16.C: Likewise. * g++.dg/ext/vla17.C: Likewise. * g++.dg/ext/vla23.C: Likewise. * g++.dg/ext/vla3.C: Likewise. * g++.dg/ext/vla6.C: Likewise. * g++.dg/ext/vla7.C: Likewise. * g++.dg/init/array24.C: Likewise. * g++.dg/init/new47.C: Likewise. * g++.dg/init/pr55497.C: Likewise. * g++.dg/opt/pr78201.C: Likewise. * g++.dg/template/vla2.C: Likewise. * g++.dg/torture/Wsizeof-pointer-memaccess1.C: Likewise. * g++.dg/torture/Wsizeof-pointer-memaccess2.C: Likewise. * g++.dg/torture/pr62127.C: Likewise. * g++.dg/torture/pr67055.C: Likewise. * g++.dg/torture/stackalign/eh-alloca-1.C: Likewise. * g++.dg/torture/stackalign/eh-inline-2.C: Likewise. * g++.dg/torture/stackalign/eh-vararg-1.C: Likewise. * g++.dg/torture/stackalign/eh-vararg-2.C: Likewise. * g++.dg/warn/Wplacement-new-size-5.C: Likewise. * g++.dg/warn/Wsizeof-pointer-memaccess-1.C: Likewise. * g++.dg/warn/Wvla-1.C: Likewise. * g++.dg/warn/Wvla-3.C: Likewise. * g++.old-deja/g++.ext/array2.C: Likewise. * g++.old-deja/g++.ext/constructor.C: Likewise. * g++.old-deja/g++.law/builtin1.C: Likewise. * g++.old-deja/g++.other/crash12.C: Likewise. * g++.old-deja/g++.other/eh3.C: Likewise. * g++.old-deja/g++.pt/array6.C: Likewise. * g++.old-deja/g++.pt/dynarray.C: Likewise. * gcc.c-torture/compile/20000923-1.c: Likewise. * gcc.c-torture/compile/20030224-1.c: Likewise. * gcc.c-torture/compile/20071108-1.c: Likewise. * gcc.c-torture/compile/20071117-1.c: Likewise. * gcc.c-torture/compile/900313-1.c: Likewise. * gcc.c-torture/compile/parms.c: Likewise. * gcc.c-torture/compile/pr17397.c: Likewise. * gcc.c-torture/compile/pr35006.c: Likewise. * gcc.c-torture/compile/pr42956.c: Likewise. * gcc.c-torture/compile/pr51354.c: Likewise. * gcc.c-torture/compile/pr52714.c: Likewise. * gcc.c-torture/compile/pr55851.c: Likewise. * gcc.c-torture/compile/pr77754-1.c: Likewise. * gcc.c-torture/compile/pr77754-2.c: Likewise. * gcc.c-torture/compile/pr77754-3.c: Likewise. * gcc.c-torture/compile/pr77754-4.c: Likewise. * gcc.c-torture/compile/pr77754-5.c: Likewise. * gcc.c-torture/compile/pr77754-6.c: Likewise. * gcc.c-torture/compile/pr78439.c: Likewise. * gcc.c-torture/compile/pr79413.c: Likewise. * gcc.c-torture/compile/pr82564.c: Likewise. * gcc.c-torture/compile/pr87110.c: Likewise. * gcc.c-torture/compile/pr99787-1.c: Likewise. * gcc.c-torture/compile/vla-const-1.c: Likewise. * gcc.c-torture/compile/vla-const-2.c: Likewise. * gcc.c-torture/execute/20010209-1.c: Likewise. * gcc.c-torture/execute/20020314-1.c: Likewise. * gcc.c-torture/execute/20020412-1.c: Likewise. * gcc.c-torture/execute/20021113-1.c: Likewise. * gcc.c-torture/execute/20040223-1.c: Likewise. * gcc.c-torture/execute/20040308-1.c: Likewise. * gcc.c-torture/execute/20040811-1.c: Likewise. * gcc.c-torture/execute/20070824-1.c: Likewise. * gcc.c-torture/execute/20070919-1.c: Likewise. * gcc.c-torture/execute/built-in-setjmp.c: Likewise. * gcc.c-torture/execute/pr22061-1.c: Likewise. * gcc.c-torture/execute/pr43220.c: Likewise. * gcc.c-torture/execute/pr82210.c: Likewise. * gcc.c-torture/execute/pr86528.c: Likewise. * gcc.c-torture/execute/vla-dealloc-1.c: Likewise. * gcc.dg/20001012-2.c: Likewise. * gcc.dg/20020415-1.c: Likewise. * gcc.dg/20030331-2.c: Likewise. * gcc.dg/20101010-1.c: Likewise. * gcc.dg/Walloca-1.c: Likewise. * gcc.dg/Walloca-10.c: Likewise. * gcc.dg/Walloca-11.c: Likewise. * gcc.dg/Walloca-12.c: Likewise. * gcc.dg/Walloca-13.c: Likewise. * gcc.dg/Walloca-14.c: Likewise. * gcc.dg/Walloca-15.c: Likewise. * gcc.dg/Walloca-2.c: Likewise. * gcc.dg/Walloca-3.c: Likewise. * gcc.dg/Walloca-4.c: Likewise. * gcc.dg/Walloca-5.c: Likewise. * gcc.dg/Walloca-6.c: Likewise. * gcc.dg/Walloca-7.c: Likewise. * gcc.dg/Walloca-8.c: Likewise. * gcc.dg/Walloca-9.c: Likewise. * gcc.dg/Walloca-larger-than-2.c: Likewise. * gcc.dg/Walloca-larger-than-3.c: Likewise. * gcc.dg/Walloca-larger-than-4.c: Likewise. * gcc.dg/Walloca-larger-than.c: Likewise. * gcc.dg/Warray-bounds-22.c: Likewise. * gcc.dg/Warray-bounds-41.c: Likewise. * gcc.dg/Warray-bounds-46.c: Likewise. * gcc.dg/Warray-bounds-48-novec.c: Likewise. * gcc.dg/Warray-bounds-48.c: Likewise. * gcc.dg/Warray-bounds-50.c: Likewise. * gcc.dg/Warray-bounds-63.c: Likewise. * gcc.dg/Warray-bounds-66.c: Likewise. * gcc.dg/Wdangling-pointer.c: Likewise. * gcc.dg/Wfree-nonheap-object-2.c: Likewise. * gcc.dg/Wfree-nonheap-object.c: Likewise. * gcc.dg/Wrestrict-17.c: Likewise. * gcc.dg/Wrestrict.c: Likewise. * gcc.dg/Wreturn-local-addr-2.c: Likewise. * gcc.dg/Wreturn-local-addr-3.c: Likewise. * gcc.dg/Wreturn-local-addr-4.c: Likewise. * gcc.dg/Wreturn-local-addr-6.c: Likewise. * gcc.dg/Wsizeof-pointer-memaccess1.c: Likewise. * gcc.dg/Wstack-usage.c: Likewise. * gcc.dg/Wstrict-aliasing-bogus-vla-1.c: Likewise. * gcc.dg/Wstrict-overflow-27.c: Likewise. * gcc.dg/Wstringop-overflow-15.c: Likewise. * gcc.dg/Wstringop-overflow-23.c: Likewise. * gcc.dg/Wstringop-overflow-25.c: Likewise. * gcc.dg/Wstringop-overflow-27.c: Likewise. * gcc.dg/Wstringop-overflow-3.c: Likewise. * gcc.dg/Wstringop-overflow-39.c: Likewise. * gcc.dg/Wstringop-overflow-56.c: Likewise. * gcc.dg/Wstringop-overflow-57.c: Likewise. * gcc.dg/Wstringop-overflow-67.c: Likewise. * gcc.dg/Wstringop-overflow-71.c: Likewise. * gcc.dg/Wstringop-truncation-3.c: Likewise. * gcc.dg/Wvla-larger-than-1.c: Likewise. * gcc.dg/Wvla-larger-than-2.c: Likewise. * gcc.dg/Wvla-larger-than-3.c: Likewise. * gcc.dg/Wvla-larger-than-4.c: Likewise. * gcc.dg/Wvla-larger-than-5.c: Likewise. * gcc.dg/analyzer/boxed-malloc-1.c: Likewise. * gcc.dg/analyzer/call-summaries-2.c: Likewise. * gcc.dg/analyzer/malloc-1.c: Likewise. * gcc.dg/analyzer/malloc-reuse.c: Likewise. * gcc.dg/analyzer/out-of-bounds-diagram-12.c: Likewise. * gcc.dg/analyzer/pr93355-localealias.c: Likewise. * gcc.dg/analyzer/putenv-1.c: Likewise. * gcc.dg/analyzer/taint-alloc-1.c: Likewise. * gcc.dg/analyzer/torture/pr93373.c: Likewise. * gcc.dg/analyzer/torture/ubsan-1.c: Likewise. * gcc.dg/analyzer/vla-1.c: Likewise. * gcc.dg/atomic/stdatomic-vm.c: Likewise. * gcc.dg/attr-alloc_size-6.c: Likewise. * gcc.dg/attr-alloc_size-7.c: Likewise. * gcc.dg/attr-alloc_size-8.c: Likewise. * gcc.dg/attr-alloc_size-9.c: Likewise. * gcc.dg/attr-noipa.c: Likewise. * gcc.dg/auto-init-uninit-36.c: Likewise. * gcc.dg/auto-init-uninit-9.c: Likewise. * gcc.dg/auto-type-1.c: Likewise. * gcc.dg/builtin-alloc-size.c: Likewise. * gcc.dg/builtin-dynamic-alloc-size.c: Likewise. * gcc.dg/builtin-dynamic-object-size-1.c: Likewise. * gcc.dg/builtin-dynamic-object-size-2.c: Likewise. * gcc.dg/builtin-dynamic-object-size-3.c: Likewise. * gcc.dg/builtin-dynamic-object-size-4.c: Likewise. * gcc.dg/builtin-object-size-1.c: Likewise. * gcc.dg/builtin-object-size-2.c: Likewise. * gcc.dg/builtin-object-size-3.c: Likewise. * gcc.dg/builtin-object-size-4.c: Likewise. * gcc.dg/builtins-64.c: Likewise. * gcc.dg/builtins-68.c: Likewise. * gcc.dg/c23-auto-2.c: Likewise. * gcc.dg/c99-const-expr-13.c: Likewise. * gcc.dg/c99-vla-1.c: Likewise. * gcc.dg/fold-alloca-1.c: Likewise. * gcc.dg/gomp/pr30494.c: Likewise. * gcc.dg/gomp/vla-2.c: Likewise. * gcc.dg/gomp/vla-3.c: Likewise. * gcc.dg/gomp/vla-4.c: Likewise. * gcc.dg/gomp/vla-5.c: Likewise. * gcc.dg/graphite/pr99085.c: Likewise. * gcc.dg/guality/guality.c: Likewise. * gcc.dg/lto/pr80778_0.c: Likewise. * gcc.dg/nested-func-10.c: Likewise. * gcc.dg/nested-func-12.c: Likewise. * gcc.dg/nested-func-13.c: Likewise. * gcc.dg/nested-func-14.c: Likewise. * gcc.dg/nested-func-15.c: Likewise. * gcc.dg/nested-func-16.c: Likewise. * gcc.dg/nested-func-17.c: Likewise. * gcc.dg/nested-func-9.c: Likewise. * gcc.dg/packed-vla.c: Likewise. * gcc.dg/pr100225.c: Likewise. * gcc.dg/pr25682.c: Likewise. * gcc.dg/pr27301.c: Likewise. * gcc.dg/pr31507-1.c: Likewise. * gcc.dg/pr33238.c: Likewise. * gcc.dg/pr41470.c: Likewise. * gcc.dg/pr49120.c: Likewise. * gcc.dg/pr50764.c: Likewise. * gcc.dg/pr51491-2.c: Likewise. * gcc.dg/pr51990-2.c: Likewise. * gcc.dg/pr51990.c: Likewise. * gcc.dg/pr59011.c: Likewise. * gcc.dg/pr59523.c: Likewise. * gcc.dg/pr61561.c: Likewise. * gcc.dg/pr78468.c: Likewise. * gcc.dg/pr78902.c: Likewise. * gcc.dg/pr79972.c: Likewise. * gcc.dg/pr82875.c: Likewise. * gcc.dg/pr83844.c: Likewise. * gcc.dg/pr84131.c: Likewise. * gcc.dg/pr87099.c: Likewise. * gcc.dg/pr87320.c: Likewise. * gcc.dg/pr89045.c: Likewise. * gcc.dg/pr91014.c: Likewise. * gcc.dg/pr93986.c: Likewise. * gcc.dg/pr98721-1.c: Likewise. * gcc.dg/pr99122-2.c: Likewise. * gcc.dg/shrink-wrap-alloca.c: Likewise. * gcc.dg/sso-14.c: Likewise. * gcc.dg/strlenopt-62.c: Likewise. * gcc.dg/strlenopt-83.c: Likewise. * gcc.dg/strlenopt-84.c: Likewise. * gcc.dg/strlenopt-91.c: Likewise. * gcc.dg/torture/Wsizeof-pointer-memaccess1.c: Likewise. * gcc.dg/torture/calleesave-sse.c: Likewise. * gcc.dg/torture/pr48953.c: Likewise. * gcc.dg/torture/pr71881.c: Likewise. * gcc.dg/torture/pr71901.c: Likewise. * gcc.dg/torture/pr78742.c: Likewise. * gcc.dg/torture/pr92088-1.c: Likewise. * gcc.dg/torture/pr92088-2.c: Likewise. * gcc.dg/torture/pr93124.c: Likewise. * gcc.dg/torture/pr94479.c: Likewise. * gcc.dg/torture/stackalign/alloca-1.c: Likewise. * gcc.dg/torture/stackalign/inline-2.c: Likewise. * gcc.dg/torture/stackalign/nested-3.c: Likewise. * gcc.dg/torture/stackalign/vararg-1.c: Likewise. * gcc.dg/torture/stackalign/vararg-2.c: Likewise. * gcc.dg/tree-ssa/20030807-2.c: Likewise. * gcc.dg/tree-ssa/20080530.c: Likewise. * gcc.dg/tree-ssa/alias-37.c: Likewise. * gcc.dg/tree-ssa/builtin-sprintf-warn-22.c: Likewise. * gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: Likewise. * gcc.dg/tree-ssa/builtin-sprintf-warn-3.c: Likewise. * gcc.dg/tree-ssa/loop-interchange-15.c: Likewise. * gcc.dg/tree-ssa/pr23848-1.c: Likewise. * gcc.dg/tree-ssa/pr23848-2.c: Likewise. * gcc.dg/tree-ssa/pr23848-3.c: Likewise. * gcc.dg/tree-ssa/pr23848-4.c: Likewise. * gcc.dg/uninit-32.c: Likewise. * gcc.dg/uninit-36.c: Likewise. * gcc.dg/uninit-39.c: Likewise. * gcc.dg/uninit-41.c: Likewise. * gcc.dg/uninit-9-O0.c: Likewise. * gcc.dg/uninit-9.c: Likewise. * gcc.dg/uninit-pr100250.c: Likewise. * gcc.dg/uninit-pr101300.c: Likewise. * gcc.dg/uninit-pr101494.c: Likewise. * gcc.dg/uninit-pr98583.c: Likewise. * gcc.dg/vla-2.c: Likewise. * gcc.dg/vla-22.c: Likewise. * gcc.dg/vla-24.c: Likewise. * gcc.dg/vla-3.c: Likewise. * gcc.dg/vla-4.c: Likewise. * gcc.dg/vla-stexp-1.c: Likewise. * gcc.dg/vla-stexp-2.c: Likewise. * gcc.dg/vla-stexp-4.c: Likewise. * gcc.dg/vla-stexp-5.c: Likewise. * gcc.dg/winline-7.c: Likewise. * gcc.target/aarch64/stack-check-alloca-1.c: Likewise. * gcc.target/aarch64/stack-check-alloca-10.c: Likewise. * gcc.target/aarch64/stack-check-alloca-2.c: Likewise. * gcc.target/aarch64/stack-check-alloca-3.c: Likewise. * gcc.target/aarch64/stack-check-alloca-4.c: Likewise. * gcc.target/aarch64/stack-check-alloca-5.c: Likewise. * gcc.target/aarch64/stack-check-alloca-6.c: Likewise. * gcc.target/aarch64/stack-check-alloca-7.c: Likewise. * gcc.target/aarch64/stack-check-alloca-8.c: Likewise. * gcc.target/aarch64/stack-check-alloca-9.c: Likewise. * gcc.target/arc/interrupt-6.c: Likewise. * gcc.target/i386/pr80969-3.c: Likewise. * gcc.target/loongarch/stack-check-alloca-1.c: Likewise. * gcc.target/loongarch/stack-check-alloca-2.c: Likewise. * gcc.target/loongarch/stack-check-alloca-3.c: Likewise. * gcc.target/loongarch/stack-check-alloca-4.c: Likewise. * gcc.target/loongarch/stack-check-alloca-5.c: Likewise. * gcc.target/loongarch/stack-check-alloca-6.c: Likewise. * gcc.target/riscv/stack-check-alloca-1.c: Likewise. * gcc.target/riscv/stack-check-alloca-10.c: Likewise. * gcc.target/riscv/stack-check-alloca-2.c: Likewise. * gcc.target/riscv/stack-check-alloca-3.c: Likewise. * gcc.target/riscv/stack-check-alloca-4.c: Likewise. * gcc.target/riscv/stack-check-alloca-5.c: Likewise. * gcc.target/riscv/stack-check-alloca-6.c: Likewise. * gcc.target/riscv/stack-check-alloca-7.c: Likewise. * gcc.target/riscv/stack-check-alloca-8.c: Likewise. * gcc.target/riscv/stack-check-alloca-9.c: Likewise. * gcc.target/sparc/setjmp-1.c: Likewise. * gcc.target/x86_64/abi/ms-sysv/ms-sysv.c: Likewise. * gcc.c-torture/compile/20001221-1.c: Don't 'dg-skip-if' for '! alloca'. * gcc.c-torture/compile/20020807-1.c: Likewise. * gcc.c-torture/compile/20050801-2.c: Likewise. * gcc.c-torture/compile/920428-4.c: Likewise. * gcc.c-torture/compile/debugvlafunction-1.c: Likewise. * gcc.c-torture/compile/pr41469.c: Likewise. * gcc.c-torture/execute/920721-2.c: Likewise. * gcc.c-torture/execute/920929-1.c: Likewise. * gcc.c-torture/execute/921017-1.c: Likewise. * gcc.c-torture/execute/941202-1.c: Likewise. * gcc.c-torture/execute/align-nest.c: Likewise. * gcc.c-torture/execute/alloca-1.c: Likewise. * gcc.c-torture/execute/pr22061-4.c: Likewise. * gcc.c-torture/execute/pr36321.c: Likewise. * gcc.dg/torture/pr8081.c: Likewise. * gcc.dg/analyzer/data-model-1.c: Don't 'dg-require-effective-target alloca'. XFAIL relevant 'dg-warning's for '! alloca'. * gcc.dg/uninit-38.c: Likewise. * gcc.dg/uninit-pr98578.c: Likewise. * gcc.dg/compat/struct-by-value-22_main.c: Comment on 'dg-require-effective-target alloca'. libstdc++-v3/ * testsuite/lib/prune.exp (proc libstdc++-dg-prune): Turn 'sorry, unimplemented: dynamic stack allocation not supported' into UNSUPPORTED.
-
- Feb 20, 2025
-
-
Jonathan Wakely authored
When linking statically to libstdc++.a (or to libstdc++_nonshared.a in the RHEL devtoolset compiler) there's a static initialization order problem where user code might be constructed before the std::chrono::tzdb_list globals, and so might try to use them after they've already been destroyed. Use the init_priority attribute on those globals so that they are initialized early. Since r15-7511-g4e7f74225116e7 we can disable the warnings for using a reserved priority using a diagnostic pragma. libstdc++-v3/ChangeLog: PR libstdc++/118811 * src/c++20/tzdb.cc (tzdb_list::_Node): Use init_priority attribute on static data members. * testsuite/std/time/tzdb_list/pr118811.cc: New test.
-
- Feb 15, 2025
-
-
Jonathan Wakely authored
Add conditional noexcept to the remaining range access functions that were not changed in r15-5669-g8692cb10e82e72. This is now being proposed for C++26 by P3623R0 (not published yet). libstdc++-v3/ChangeLog: * include/bits/range_access.h (rbegin, rend, crbegin, crend): Add conditional noexcept, as per P3623R0. * testsuite/24_iterators/headers/iterator/range_access.cc: Add noexcept-specifier to rbegin, rend, crbegin and crend declarations.
-
Jonathan Wakely authored
Instead of a test with { target c++11_only } and another with c++14_only and another with c++17 we can have a single test that uses { target c++11 }. This avoids needing to make edits to three very similar tests. Also fix the signatures for std::cbegin and std::cend which had the wrong expression in the trailing-return-type and were missing their constexpr and conditional noexcept (which were always present even in C++14). That was wrong in two files, but now only needs to be fixed in one place! libstdc++-v3/ChangeLog: * testsuite/24_iterators/headers/iterator/range_access_c++11.cc: Removed. * testsuite/24_iterators/headers/iterator/range_access_c++14.cc: Removed. * testsuite/24_iterators/headers/iterator/range_access_c++17.cc: Removed. * testsuite/24_iterators/headers/iterator/range_access.cc: New test.
-
- Feb 14, 2025
-
-
Jonathan Wakely authored
_Rb_tree::_M_equal_range calls make_pair unqualified, which means it uses ADL. As the new testcase shows, this can find something other than std::make_pair. Rather than just changing it to use a qualified call, remove the use of make_pair entirely. We don't need to deduce any types here, we know exactly what type of std::pair we want to construct, so do that explicitly. libstdc++-v3/ChangeLog: * include/bits/stl_tree.h (_Rb_tree::_M_equal_range): Replace unqualified call to make_pair with explicit construction of std::pair. * testsuite/23_containers/set/operations/equal_range_adl.cc: New test.
-
- Feb 08, 2025
-
-
Thomas Schwinge authored
For GCN, this avoids ICEs further down the compilation pipeline. For nvptx, there's effectively no change: in presence of exception handling constructs, instead of 'sorry, unimplemented: target cannot support nonlocal goto', we now emit 'sorry, unimplemented: exception handling not supported'. Additionally, turn test cases into UNSUPPORTED if running into 'sorry, unimplemented: exception handling not supported'. gcc/ * config/gcn/gcn.md (exception_receiver): 'define_expand'. * config/nvptx/nvptx.md (exception_receiver): Likewise. gcc/testsuite/ * lib/gcc-dg.exp (gcc-dg-prune): Turn 'sorry, unimplemented: exception handling not supported' into UNSUPPORTED. * gcc.dg/pr104464.c: Remove GCN XFAIL. libstdc++-v3/ * testsuite/lib/prune.exp (libstdc++-dg-prune): Turn 'sorry, unimplemented: exception handling not supported' into UNSUPPORTED.
-
Thomas Schwinge authored
In Subversion r268025 (Git commit 3f21b8e3) "Add dg-require-effective-target exceptions", effective-target 'exceptions' was added, which "says that AMD GCN does not support [exception handling]". In Subversion r279246 (Git commit a9046e98) "MSP430: Add -fno-exceptions multilib", effective-target 'exceptions_enabled' was added "to check if the testing configuration supports exceptions". Testing "if exceptions are unsupported or disabled (e.g. by passing -fno-exceptions)" works as expected if exception handling is disabled at the front-end level ('-fno-exceptions'; the "exceptions are [...] disabled" case): exceptions_enabled2066068.cc: In function ‘void foo()’: exceptions_enabled2066068.cc:3:27: error: exception handling disabled, use ‘-fexceptions’ to enable However, effective-target 'exceptions_enabled' additionally assumes that "If exceptions aren't supported [by the target], then they're not enabled". This is not correct: it's not unlikely that, in presence of explicit/implicit '-fexceptions', exception handling code gets fully optimized away by the compiler, and therefore effective-target 'exceptions_enabled' test cases may PASS even for targets that don't support effective-target 'exceptions'; these two effective-targets are orthogonal concepts. (For completeness: code with trivial instances of C++ exception handling may translate into simple '__cxa_allocate_exception', '__cxa_throw' function calls without requiring any back end-level "exceptions magic", and then trigger unresolved symbols at link time, if these functions are not available.) This change only affects GCN, as that one currently is the only target declared as not supporting effective-target 'exceptions'. gcc/ * doc/sourcebuild.texi (Effective-Target Keywords): Clarify that effective-target 'exceptions' and 'exceptions_enabled' are orthogonal. gcc/testsuite/ * lib/gcc-dg.exp (gcc-dg-prune): Clarify effective-target 'exceptions_enabled'. * lib/target-supports.exp (check_effective_target_exceptions_enabled): Don't consider effective-target 'exceptions'. libstdc++-v3/ * testsuite/lib/prune.exp (libstdc++-dg-prune): Clarify effective-target 'exceptions_enabled'.
-
- Feb 07, 2025
-
-
Giuseppe D'Angelo authored
The code was caching the result of `invoke(proj, *it)` in a local `auto &&` variable. The problem is that this may create dangling references, for instance in case `proj` is `std::identity` (the common case) and `*it` produces a prvalue: lifetime extension does not apply here due to the expressions involved. Instead, store (and lifetime-extend) the result of `*it` in a separate variable, then project that variable. While at it, also forward the result of the projection to the predicate, so that the predicate can act on the proper value category. libstdc++-v3/ChangeLog: PR libstdc++/118160 PR libstdc++/100249 * include/bits/ranges_algo.h (__is_permutation_fn): Avoid a dangling reference by storing the result of the iterator dereference and the result of the projection in two distinct variables, in order to lifetime-extend each one. Forward the projected value to the predicate. * testsuite/25_algorithms/is_permutation/constrained.cc: Add a test with a range returning prvalues. Test it in a constexpr context, in order to rely on the compiler to catch UB. Signed-off-by:
Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
-
Jonathan Wakely authored
Because basic_ostream::sentry::~sentry is implicitly noexcept, we can't let any exceptions escape from it, or the program would terminate. If the streambuf's sync() function throws, or if it returns an error and setting badbit in the stream state throws, then the program would terminate. LWG 835 intended to prevent exceptions from being thrown by the std::basic_ostream::sentry destructor, but failed to cover the case where the streambuf's sync() member throws an exception. LWG 4188 is needed to fix that part. In any case, LWG 835 was never implemented for libstdc++ so this does that, as well as my proposed fix for 4188 (that badbit should be set if pubsync() exits via an exception). In order to avoid a second try-catch block to handle an exception that might be thrown by setting badbit, this introduces an RAII helper class that temporarily clears the stream's exceptions mask, then restores it afterwards. The try-catch block doesn't handle the forced_unwind exception explicitly, because catching and rethrowing that would just terminate when it reached the sentry's implicit noexcept(true) anyway. libstdc++-v3/ChangeLog: * include/bits/ostream.h (basic_ostream::_Disable_exceptions): RAII helper type. (basic_ostream::sentry::~sentry): Use _Disable_exceptions. Add try-catch block around call to pubsync. * testsuite/27_io/basic_ostream/exceptions/char/lwg4188.cc: New test. * testsuite/27_io/basic_ostream/exceptions/wchar_t/lwg4188.cc: New test.
-
- Feb 05, 2025
-
-
Rainer Orth authored
This patch commit c6977f76 Author: Andreas Schwab <schwab@suse.de> Date: Tue Jan 21 23:50:15 2025 +0100 libstdc++: correct symbol version of typeinfo for bfloat16_t on RISC-V broke the libstdc++-abi/abi_check test on Solaris: the log shows 1 incompatible symbols 0 Argument "{CXXABI_1.3.15}" isn't numeric in numeric eq (==) at /vol/gcc/src/hg/master/local/libstdc++-v3/scripts/extract_symvers.pl line 129. version status: incompatible type: uncategorized status: added The problem has two parts: * The patch above introduced a new version in libstdc++.so, CXXABI_1.3.16, which everywhere but on RISC-V contains no symbols (a weak version). This is the first time this happened in libstdc++. * Solaris uses scripts/extract_symvers.pl to determine the version info. The script currently chokes on the pvs output for weak versions: libstdc++.so.6.0.34 - CXXABI_1.3.16 [WEAK]: {CXXABI_1.3.15}; instead of libstdc++.so.6.0.34 - CXXABI_1.3.16: {CXXABI_1.3.15}; While this patch hardens the script to cope with weak versions, there's no reason to introduce them in the first place. So the new version is only created on __riscv. Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu. 2025-01-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> Jonathan Wakely <jwakely@redhat.com> libstdc++-v3: PR libstdc++/118701 * config/abi/pre/gnu.ver (CXXABI_1.3.16): Move __riscv guard around version. * scripts/extract_symvers.pl: Allow for weak versions. * testsuite/util/testsuite_abi.cc (check_version): Wrap CXXABI_1.3.16 in __riscv.
-
- Jan 31, 2025
-
-
Patrick Palka authored
This fixes flat_map/multimap::insert_range by just generalizing the insert implementation to handle heterogenous iterator/sentinel pair. I'm not sure we can do better than this, e.g. we can't implement it in terms of the adapted containers' insert_range because that'd require two passes over the range. For flat_set/multiset, we can implement insert_range directly in terms of the adapted container's insert_range. A fallback implementation is also provided if insert_range isn't available, as is the case for std::deque currently. PR libstdc++/118156 libstdc++-v3/ChangeLog: * include/std/flat_map (_Flat_map_impl::_M_insert): Generalized version of insert taking heterogenous iterator/sentinel pair. (_Flat_map_impl::insert): Dispatch to _M_insert. (_Flat_map_impl::insert_range): Likewise. (flat_map): Export _Flat_map_impl::insert_range. (flat_multimap): Likewise. * include/std/flat_set (_Flat_set_impl::insert_range): Reimplement directly, not in terms of insert. (flat_set): Export _Flat_set_impl::insert_range. (flat_multiset): Likewise. * testsuite/23_containers/flat_map/1.cc (test06): New test. * testsuite/23_containers/flat_multimap/1.cc (test06): New test. * testsuite/23_containers/flat_multiset/1.cc (test06): New test. * testsuite/23_containers/flat_set/1.cc (test06): New test. Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
Patrick Palka authored
In some cases we're wrongly returning an iterator to (one past) the last element inserted instead of to the first element inserted. libstdc++-v3/ChangeLog: * include/bits/stl_bvector.h (vector<bool>::insert_range): Consistently return an iterator pointing to the first element inserted. * include/bits/vector.tcc (vector::insert_range): Likewise. * testsuite/23_containers/vector/bool/modifiers/insert/insert_range.cc: Verify insert_range return values. * testsuite/23_containers/vector/modifiers/insert/insert_range.cc: Likewise. Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
- Jan 30, 2025
-
-
Jonathan Wakely authored
The std::latch::max() function assumes that the returned value can be represented by ptrdiff_t, which is true when __platform_wait_t is int (e.g. on Linux) but not when it's unsigned long, which is the case for most other 64-bit targets. We should use the smaller of PTRDIFF_MAX and std::numeric_limits<__platform_wait_t>::max(). Use std::cmp_less to do a safe comparison that works for all types. We can also use std::cmp_less and std::cmp_equal in std::latch::count_down so that we don't need to deal with comparisons between signed and unsigned. Also add a missing precondition check to constructor and fix the existing check in count_down which was duplicated by mistake. libstdc++-v3/ChangeLog: PR libstdc++/98749 * include/std/latch (latch::max()): Ensure the return value is representable as the return type. (latch::latch(ptrdiff_t)): Add assertion. (latch::count_down): Fix copy & pasted duplicate assertion. Use std::cmp_equal to compare __platform_wait_t and ptrdiff_t values. (latch::_M_a): Use defined constant for alignment. * testsuite/30_threads/latch/1.cc: Check max(). Check constant initialization works for values in the valid range. Check alignment.
-
- Jan 29, 2025
-
-
Patrick Palka authored
The range adaptor perfect forwarding simplification mechanism is currently only enabled for trivially copyable bound arguments, to prevent undesirable copies of complex objects. But "trivially copyable" is the wrong property to check for here, since a move-only type with a trivial move constructor is considered trivially copyable, and after P2492R2 we can't assume copy constructibility of the bound arguments. This patch makes the mechanism more specifically check for trivial copy constructibility instead so that it's properly disabled for move-only bound arguments. PR libstdc++/118413 libstdc++-v3/ChangeLog: * include/std/ranges (views::__adaptor::_Partial): Adjust constraints on the "simple" partial specializations to require is_trivially_copy_constructible_v instead of is_trivially_copyable_v. * testsuite/std/ranges/adaptors/adjacent_transform/1.cc (test04): Extend P2494R2 test. * testsuite/std/ranges/adaptors/transform.cc (test09): Likewise. Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
- Jan 27, 2025
-
-
Andreas Schwab authored
RISC-V only gained support for bfloat16_t after gcc 14. Passes libstdc++/check_abi on {x86_64,aarch64,ppc64le,riscv64,s390x}-suse-linux. PR libstdc++/118563 * testsuite/util/testsuite_abi.cc (check_version): Add CXXABI_1.3.16. * config/abi/pre/gnu.ver (CXXABI_1.3.14) [__riscv]: Exclude typeinfo for bfloat16_t. (CXXABI_1.3.16) [__riscv]: Add it here.
-
- Jan 20, 2025
-
-
Giuseppe D'Angelo authored
As reported in PR118185, std::ranges::clamp does not correctly forward the projected value to the comparator. Add the missing forward. libstdc++-v3/ChangeLog: PR libstdc++/118185 PR libstdc++/100249 * include/bits/ranges_algo.h (__clamp_fn): Correctly forward the projected value to the comparator. * testsuite/25_algorithms/clamp/118185.cc: New test. Signed-off-by:
Giuseppe D'Angelo <giuseppe.dangelo@kdab.com> Reviewed-by:
Patrick Palka <ppalka@redhat.com> Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
- Jan 16, 2025
-
-
Jonathan Wakely authored
Do not report an error for (is_other(s1) && is_other(s2)) as the standard originally said, nor for (is_other(s1) || is_other(s2)) as libstdc++ was doing. We can compare inode numbers for special files and so give sensible answers. libstdc++-v3/ChangeLog: PR libstdc++/118158 * src/c++17/fs_ops.cc (fs::equivalent): Remove error reporting for is_other(s1) && is_other(s2) case, as per LWG 2937. * testsuite/27_io/filesystem/operations/pr118158.cc: New test.
-
- Jan 15, 2025
-
-
Jonathan Wakely authored
This test should use __cpp_lib_ios_noreplace rather than the internal __glibcxx_ios_noreplace macro. libstdc++-v3/ChangeLog: * testsuite/27_io/ios_base/types/openmode/case_label.cc: Use standard feature test macro not internal one.
-
Jonathan Wakely authored
The alloc_ptr.cc test for std::set tries to use C++17 features unconditionally, and tries to use the C++23 range members which haven't been implemented for std::set yet. Some of the range checks are left in place but commented out, so they can be added after the ranges members are implemented. Others (such as prepend_range) are not valid for std::set at all. Also fix uses of internal feature test macros in two other tests, which should use the standard __cpp_lib_xxx macros. libstdc++-v3/ChangeLog: * testsuite/23_containers/set/requirements/explicit_instantiation/alloc_ptr.cc: Guard node extraction checks with feature test macro. Remove calls to non-existent range members. * testsuite/23_containers/forward_list/requirements/explicit_instantiation/alloc_ptr.cc: Use standard macro not internal one. * testsuite/23_containers/list/requirements/explicit_instantiation/alloc_ptr.cc: Likewise.
-
Jonathan Wakely authored
libstdc++-v3/ChangeLog: * testsuite/28_regex/traits/char/transform_primary.cc: Fix subclause numbering in references to the standard.
-
Jakub Jelinek authored
c++: Delete defaulted operator <=> if std::strong_ordering::equal doesn't convert to its rettype [PR118387] Note, the PR raises another problem. If on the same testcase the B b; line is removed, we silently synthetize operator<=> which will crash at runtime due to returning without a return statement. That is because the standard says that in that case it should return static_cast<int>(std::strong_ordering::equal); but I can't find anywhere wording which would say that if that isn't valid, the function is deleted. https://eel.is/c++draft/class.compare#class.spaceship-2.2 seems to talk just about cases where there are some members and their comparison is invalid it is deleted, but here there are none and it follows https://eel.is/c++draft/class.compare#class.spaceship-3.sentence-2 So, we synthetize with tf_none, see the static_cast is invalid, don't add error_mark_node statement silently, but as the function isn't deleted, we just silently emit it. Should the standard be amended to say that the operator should be deleted even if it has no elements and the static cast from https://eel.is/c++draft/class.compare#class.spaceship-3.sentence-2 On Fri, Jan 10, 2025 at 12:04:53PM -0500, Jason Merrill wrote: > That seems pretty obviously what we want, and is what the other compilers > implement. This patch implements it then. 2025-01-15 Jakub Jelinek <jakub@redhat.com> PR c++/118387 * method.cc (build_comparison_op): Set bad if std::strong_ordering::equal doesn't convert to rettype. * g++.dg/cpp2a/spaceship-err6.C: Expect another error. * g++.dg/cpp2a/spaceship-synth17.C: Likewise. * g++.dg/cpp2a/spaceship-synth-neg6.C: Likewise. * g++.dg/cpp2a/spaceship-synth-neg7.C: New test. * testsuite/25_algorithms/default_template_value.cc (Input::operator<=>): Use auto as return type rather than bool.
-
- Jan 12, 2025
-
-
Torbjörn SVENSSON authored
When running tests using the "sim" config, the command is launched in non-readonly mode and the text retrieved from the expect command will then replace all LF with CRLF. (The problem can be found in sim_load where it calls remote_spawn without an input file). libstdc++-v3/ChangeLog: * testsuite/27_io/print/1.cc: Allow both LF and CRLF in test. * testsuite/27_io/print/3.cc: Likewise. Signed-off-by:
Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
-
Torbjörn SVENSSON authored
Test assumes libatomic.a is always available, but for some embedded targets, there is no libatomic.a and the test thus fail. libstdc++-v3/ChangeLog: * testsuite/29_atomics/atomic_float/compare_exchange_padding.cc: Use effective-target libatomic_available. Signed-off-by:
Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
-
- Jan 08, 2025
-
-
Giuseppe D'Angelo authored
This commit implements P2447R6. The code is straightforward (just one extra constructor, with constraints and conditional explicit). I decided to suppress -Winit-list-lifetime because otherwise it would give too many false positives. The new constructor is meant to be used as a parameter-passing interface (this is a design choice, see P2447R6/§2) and, as such, the initializer_list won't dangle despite GCC's warnings. The new constructor isn't 100% backwards compatible. A couple of examples are included in Annex C, but I have also lifted some more from R4. A new test checks for the old and the new behaviors. libstdc++-v3/ChangeLog: * include/bits/version.def: Add the new feature-testing macro. * include/bits/version.h: Regenerate. * include/std/span: Add constructor from initializer_list. * testsuite/23_containers/span/init_list_cons.cc: New test. * testsuite/23_containers/span/init_list_cons_neg.cc: New test. Signed-off-by:
Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
-
Jonathan Wakely authored
The current check for negative times (i.e. before the epoch) only checks for a negative number of seconds. For a time 1ms before the epoch the seconds part will be zero, but the futex syscall will still fail with an EINVAL error. Extend the check to handle this case. This change adds a redundant check in the headers too, so that we avoid even calling into the library for negative times. Both checks can be marked [[unlikely]]. The check in the headers avoids the cost of splitting the time into seconds and nanoseconds and then making a PLT call. The check inside the library matches where we were checking already, and fixes existing binaries that were compiled against older headers but use a newer libstdc++.so.6 at runtime. libstdc++-v3/ChangeLog: PR libstdc++/118093 * include/bits/atomic_futex.h (_M_load_and_test_until_impl): Return false for times before the epoch. * src/c++11/futex.cc (_M_futex_wait_until): Extend check for negative times to check for subsecond times. Add unlikely attribute. (_M_futex_wait_until_steady): Likewise. * testsuite/30_threads/future/members/118093.cc: New test.
-
Jonathan Wakely authored
We have several overloads of std::deque::_M_insert_aux, one of which is variadic and called by std::deque::emplace. With a suitable set of arguments to emplace, it's possible for one of the non-variadic _M_insert_aux overloads to be selected by overload resolution, making emplace ill-formed. Rename the variadic _M_insert_aux to _M_emplace_aux so that calls to emplace never select an _M_insert_aux overload. Also add an inline _M_insert_aux for the const lvalue overload that is called from insert(const_iterator, const value_type&). libstdc++-v3/ChangeLog: PR libstdc++/90389 * include/bits/deque.tcc (_M_insert_aux): Rename variadic overload to _M_emplace_aux. * include/bits/stl_deque.h (_M_insert_aux): Define inline. (_M_emplace_aux): Declare. * testsuite/23_containers/deque/modifiers/emplace/90389.cc: New test.
-
- Jan 02, 2025
-
-
Jakub Jelinek authored
-
- Dec 29, 2024
-
-
Hans-Peter Nilsson authored
These two long-running tests happened to fail for me when run in parallel (nprocs - 1) compared to a serial run, for target mmix on my laptop. The runtime is 3m40s for 3.cc before this change, and 0.9s afterwards. * testsuite/std/time/year_month_day/3.cc (test01): Add ifdeffery to limit the tested dates. For simulators, pass start and end dates limiting the tested range to 100000 days, centered on days (0). * testsuite/std/time/year_month_day/4.cc: Ditto.
-
- Dec 28, 2024
-
-
Jakub Jelinek authored
The test used #include "<generator>", so FAILed everywhere with fatal error: <generator>: No such file or directory 2024-12-28 Jakub Jelinek <jakub@redhat.com> PR libstdc++/118196 * testsuite/24_iterators/range_generators/pr118196.cc: Include <generator> rather than "<generator>".
-
- Dec 27, 2024
-
-
Arsen Arsenović authored
libstdc++-v3/ChangeLog: PR libstdc++/118196 * include/std/generator (generator::operator=(generator)): Add missing 'return *this;'. * testsuite/24_iterators/range_generators/pr118196.cc: New test.
-
Arsen Arsenović authored
This overload requires constructible_from<remove_cvref_t<yielded>, const remove_reference_t<yielded>&> ... but then tries to construct remove_cvref_t<yielded> implicitly, which means it imposes an additional constraint not in the standard. libstdc++-v3/ChangeLog: PR libstdc++/118022 * include/std/generator (_Promise_erased::yield_value(const _Yielded_deref&)): Don't implicit-constuct _Yielded_decvref. * testsuite/24_iterators/range_generators/pr118022.cc: New test.
-
- Dec 19, 2024
-
-
François Dumont authored
The fancy allocator pointer type support is added to std::map, std::multimap, std::multiset and std::set through the underlying std::_Rb_tree class. To respect ABI a new parralel hierarchy of node types has been added. This change introduces new class template parameterized on the allocator's void_pointer type, __rb_tree::_Node_base, and new class templates parameterized on the allocator's pointer type, __rb_tree::_Node, __rb_tree::_Iterator. The iterator class template is used for both iterator and const_iterator. Whether std::_Rb_tree<K, V, KoV, C, A> should use the old _Rb_tree_node<V> or new __rb_tree::_Node<A::pointer> type family internally is controlled by a new __rb_tree::_Node_traits traits template. Because std::pointer_traits and std::__to_address are not defined for C++98, there is no way to support fancy pointers in C++98. For C++98 the _Node_traits traits always choose the old _Rb_tree_node family. In case anybody is currently using std::_Rb_tree with an allocator that has a fancy pointer, this change would be an ABI break, because their std::_Rb_tree instantiations would start to (correctly) use the fancy pointer type. If the fancy pointer just contains a single pointer and so has the same size, layout, and object representation as a raw pointer, the code might still work (despite being an ODR violation). But if their fancy pointer has a different representation, they would need to recompile all their code using that allocator with std::_Rb_tree. Because std::_Rb_tree will never use fancy pointers in C++98 mode, recompiling everything to use fancy pointers isn't even possible if mixing C++98 and C++11 code that uses std::_Rb_tree. To alleviate this problem, compiling with -D_GLIBCXX_USE_ALLOC_PTR_FOR_RB_TREE=0 will force std::_Rb_tree to have the old, non-conforming behaviour and use raw pointers internally. For testing purposes, compiling with -D_GLIBCXX_USE_ALLOC_PTR_FOR_RB_TREE=9001 will force std::_Rb_tree to always use the new node types. This macro is currently undocumented, which needs to be fixed. As _Rb_tree is using _Base_ptr to represent the tree this change also simplifies the implementation by removing all the const pointer types and associated methods. libstdc++-v3/ChangeLog: PR libstdc++/57272 * include/bits/stl_tree.h [_GLIBCXX_USE_ALLOC_PTR_FOR_RB_TREE]: New macro to control usage of the code required to support fancy allocator pointer type. (_Rb_tree_node_base::_Const_Base_ptr): Remove. (_Rb_tree_node_base::_S_minimum, _Rb_tree_node_base::_S_maximum): Remove overloads for _Const_Base_ptr. (_Rb_tree_node_base::_M_base_ptr()): New. (_Rb_tree_node::_Link_type): Remove. (_Rb_tree_node::_M_node_ptr()): New. (__rb_tree::_Node_base<>): New. (__rb_tree::_Header<>): New. (__rb_tree::_Node<>): New. (_Rb_tree_increment(const _Rb_tree_node_base*)): Remove declaration. (_Rb_tree_decrement(const _Rb_tree_node_base*)): Remove declaration. (_Rb_tree_iterator<>::_Self): Remove. (_Rb_tree_iterator<>::_Link_type): Rename into... (_Rb_tree_iterator<>::_Node_ptr): ...this. (_Rb_tree_const_iterator<>::_Link_type): Rename into... (_Rb_tree_const_iterator<>::_Node_ptr): ...this. (_Rb_tree_const_iterator<>::_M_const_cast): Remove. (_Rb_tree_const_iterator<>::_M_node): Change type into _Base_ptr. (__rb_tree::_Iterator<>): New. (__rb_tree::_Node_traits<>): New. (_Rb_tree<>::_Node_base, _Rb_tree::_Node): New. (_Rb_tree<>::_Link_type): Rename into... (_Rb_tree<>::_Node_ptr): ...this. (_Rb_tree<>::_Const_Base_ptr, _Rb_tree<>::_Const_Node_ptr): Remove. (_Rb_tree<>::_M_mbegin): Remove. (_Rb_tree<>::_M_begin_node()): New. (_S_key(const _Node&)): New. (_S_key(_Base_ptr)): New, call latter. (_S_key(_Node_ptr)): Likewise. (_Rb_tree<>::_S_left(_Const_Base_ptr)): Remove. (_Rb_tree<>::_S_right(_Const_Base_ptr)): Remove. (_Rb_tree<>::_S_maximum(_Const_Base_ptr)): Remove. (_Rb_tree<>::_S_minimum(_Const_Base_ptr)): Remove. * testsuite/23_containers/map/allocator/ext_ptr.cc: New test case. * testsuite/23_containers/multimap/allocator/ext_ptr.cc: New test case. * testsuite/23_containers/multiset/allocator/ext_ptr.cc: New test case. * testsuite/23_containers/set/allocator/ext_ptr.cc: New test case. * testsuite/23_containers/set/requirements/explicit_instantiation/alloc_ptr.cc: New test case. * testsuite/23_containers/set/requirements/explicit_instantiation/alloc_ptr_ignored.cc: New test case.
-
Patrick Palka authored
This implements the C++23 container adaptors std::flat_set and std::flat_multiset from P1222R4. The implementation is essentially an simpler and pared down version of std::flat_map. libstdc++-v3/ChangeLog: * include/Makefile.am: Add new header <flat_set>. * include/Makefile.in: Regenerate. * include/bits/version.def (__cpp_flat_set): Define. * include/bits/version.h: Regenerate * include/precompiled/stdc++.h: Include <flat_set>. * include/std/flat_set: New file. * src/c++23/std.cc.in: Export <flat_set>. * testsuite/23_containers/flat_multiset/1.cc: New test. * testsuite/23_containers/flat_set/1.cc: New test. Co-authored-by:
Jonathan Wakely <jwakely@redhat.com> Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-