Skip to content
Snippets Groups Projects
  1. Feb 28, 2025
    • Jonathan Wakely's avatar
      libstdc++: Fix ranges::iter_move handling of rvalues [PR106612] · a8ee522c
      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: default avatarPatrick Palka <ppalka@redhat.com>
      a8ee522c
    • Jonathan Wakely's avatar
      libstdc++: Fix ranges::move and ranges::move_backward to use iter_move [PR105609] · 3866ca79
      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.
      3866ca79
    • Jonathan Wakely's avatar
      libstdc++: Add static_assertions to ranges::to adaptor factory [PR112803] · a9cfcd0d
      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.
      a9cfcd0d
    • Patrick Palka's avatar
      libstdc++: Fix constraint recursion in basic_const_iterator relops [PR112490] · 4342c50c
      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: default avatarJonathan Wakely <jwakely@redhat.com>
      4342c50c
  2. Feb 25, 2025
    • Giuseppe D'Angelo's avatar
      libstdc++: add support for constexpr stable_sort (P2562R1) · ff43f985
      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: default avatarGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>
      ff43f985
    • François Dumont's avatar
      libstdc++: [_Hashtable] Fix hash code cache usage when stateful hash functor · bcc8dea6
      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.
      bcc8dea6
    • Patrick Palka's avatar
      libstdc++: Implement LWG 4027 change to possibly-const-range [PR118083] · 1b9e4fe2
      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: default avatarJonathan Wakely <jwakely@redhat.com>
      1b9e4fe2
  3. Feb 22, 2025
    • Thomas Schwinge's avatar
      Turn test cases into UNSUPPORTED if running into 'sorry, unimplemented:... · 0128fa8b
      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.
      0128fa8b
  4. Feb 20, 2025
    • Jonathan Wakely's avatar
      libstdc++: Use init_priority attribute for tzdb globals [PR118811] · 99f57446
      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.
      99f57446
  5. Feb 15, 2025
    • Jonathan Wakely's avatar
      libstdc++: Add conditional noexcept to remaining range access functions · 7bc72a3d
      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.
      7bc72a3d
    • Jonathan Wakely's avatar
      libstdc++: Combine three tests into one · 08f70200
      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.
      08f70200
  6. Feb 14, 2025
    • Jonathan Wakely's avatar
      libstdc++: Fix use of make_pair that used ADL · d5fb86cb
      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.
      d5fb86cb
  7. Feb 08, 2025
    • Thomas Schwinge's avatar
      GCN, nvptx: 'sorry, unimplemented: exception handling not supported' · 63121656
      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.
      63121656
    • Thomas Schwinge's avatar
      Clarify that effective-targets 'exceptions' and 'exceptions_enabled' are orthogonal · 9f4feba6
      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'.
      9f4feba6
  8. Feb 07, 2025
    • Giuseppe D'Angelo's avatar
      libstdc++: fix a dangling reference crash in ranges::is_permutation [PR118160] · 2a2bd96d
      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: default avatarGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>
      2a2bd96d
    • Jonathan Wakely's avatar
      libstdc++: Handle exceptions in std::ostream::sentry destructor · 6e758f37
      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.
      6e758f37
  9. Feb 05, 2025
    • Rainer Orth's avatar
      libstdc++: Fix gnu.ver CXXABI_1.3.16 for Solaris [PR118701] · 6b49883e
      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.
      6b49883e
  10. Jan 31, 2025
    • Patrick Palka's avatar
      libstdc++: Fix flat_foo::insert_range for non-common ranges [PR118156] · a9172b10
      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: default avatarJonathan Wakely <jwakely@redhat.com>
      a9172b10
    • Patrick Palka's avatar
      libstdc++: Fix return value of vector::insert_range · ee797739
      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: default avatarJonathan Wakely <jwakely@redhat.com>
      ee797739
  11. Jan 30, 2025
    • Jonathan Wakely's avatar
      libstdc++: Use safe integer comparisons in std::latch [PR98749] · 34d8c842
      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.
      34d8c842
  12. Jan 29, 2025
    • Patrick Palka's avatar
      libstdc++: Fix views::transform(move_only_fn{}) forwarding [PR118413] · 09d1cbee
      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: default avatarJonathan Wakely <jwakely@redhat.com>
      09d1cbee
  13. Jan 27, 2025
    • Andreas Schwab's avatar
      libstdc++: correct symbol version of typeinfo for bfloat16_t on RISC-V · c6977f76
      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.
      c6977f76
  14. Jan 20, 2025
  15. Jan 16, 2025
    • Jonathan Wakely's avatar
      libstdc++: Implement LWG 2937 for std::filesystem::equivalent [PR118158] · 301a961f
      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.
      301a961f
  16. Jan 15, 2025
    • Jonathan Wakely's avatar
      libstdc++: Fix use of internal feature test macro in test · 79d55040
      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.
      79d55040
    • Jonathan Wakely's avatar
      libstdc++: Fix fancy pointer test for std::set · f079feec
      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.
      f079feec
    • Jonathan Wakely's avatar
      libstdc++: Fix comments in test that reference wrong subclause of C++11 · 9cc31b4e
      Jonathan Wakely authored
      libstdc++-v3/ChangeLog:
      
      	* testsuite/28_regex/traits/char/transform_primary.cc: Fix
      	subclause numbering in references to the standard.
      9cc31b4e
    • Jakub Jelinek's avatar
      c++: Delete defaulted operator <=> if std::strong_ordering::equal doesn't... · 18f6bb98
      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.
      18f6bb98
  17. Jan 12, 2025
  18. Jan 08, 2025
    • Giuseppe D'Angelo's avatar
      libstdc++: add initializer_list constructor to std::span (P2447R6) · 5db06873
      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: default avatarGiuseppe D'Angelo <giuseppe.dangelo@kdab.com>
      5db06873
    • Jonathan Wakely's avatar
      libstdc++: Fix std::future::wait_until for subsecond negative times [PR118093] · 8ade3c3e
      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.
      8ade3c3e
    • Jonathan Wakely's avatar
      libstdc++: Fix std::deque::emplace calling wrong _M_insert_aux [PR90389] · 5f44b177
      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.
      5f44b177
  19. Jan 02, 2025
  20. Dec 29, 2024
    • Hans-Peter Nilsson's avatar
      libstdc++-v3/testsuite/.../year_month_day/3.cc, 4.cc: Cut down for simulators · 4da027d8
      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.
      4da027d8
  21. Dec 28, 2024
    • Jakub Jelinek's avatar
      libstdc++: Fix up pr118196.cc test [PR118196] · a326ecf5
      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>".
      a326ecf5
  22. Dec 27, 2024
    • Arsen Arsenović's avatar
      libstdc++: add missing return in generator assignment operator [PR118196] · 9a1cb52c
      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.
      9a1cb52c
    • Arsen Arsenović's avatar
      libstdc++: don't implicit-construct _Yielded_decvref [PR118022] · 5a41ab8d
      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.
      5a41ab8d
  23. Dec 19, 2024
    • François Dumont's avatar
      libstdc++: Add fancy pointer support to std::map and std::set [PR57272] · 23df3c3a
      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.
      23df3c3a
    • Patrick Palka's avatar
      libstdc++: Implement C++23 <flat_set> (P1222R4) · e3fab345
      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: default avatarJonathan Wakely <jwakely@redhat.com>
      Reviewed-by: default avatarJonathan Wakely <jwakely@redhat.com>
      e3fab345
Loading