ite/23_containers/inplace_vector/relops.cc: New file.
> * testsuite/23_containers/inplace_vector/version.cc: New file.
> * testsuite/util/testsuite_iterators.h (input_iterator_wrapper::base):
> Define.
>
> Reviewed-by: Patrick Palka
> Reviewed-by: Jonathan Wak
On Thu, 17 Jul 2025, Jonathan Wakely wrote:
> On 17/07/25 11:26 -0400, Patrick Palka wrote:
> > On Thu, 17 Jul 2025, Tomasz Kamiński wrote:
> >
> > > From: Jonathan Wakely
> > >
> > > Implement std::inplace_vector as specified in P0843R14, without fol
On Thu, 17 Jul 2025, Jonathan Wakely wrote:
> On 17/07/25 15:31 +0200, Tomasz Kamiński wrote:
> > From: Jonathan Wakely
> >
> > Implement std::inplace_vector as specified in P0843R14, without follow
> > up papers, in particular P3074R7 (trivial unions). In consequence
> > inplace_vector can be u
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The offset-based partial specialization of _CachedPosition for
random-access iterators is currently only selected if the offset type is
smaller than the iterator type. Before r12-1018-g46ed811bcb4b86 this
made sense since the m
Tested on x86_64-pc-linux-gnu, does this look OK for trunk only
(since it impacts ABI)?
Changes in v2:
- Condition on forward_iterator instead of default_initializable.
-- >8 --
LWG 3569 adjusted join_view's iterator specification to handle non
default-constructible iterators by wrapping the c
On Tue, 15 Jul 2025, Patrick Palka wrote:
> On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Tue, Jul 15, 2025 at 3:55 PM Patrick Palka wrote:
> > On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
> >
> > > On Tue, Jul
On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Jul 15, 2025 at 3:55 PM Patrick Palka wrote:
> On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
>
> > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka
> wrote:
> > Tested on x86_64-pc-li
On Tue, 15 Jul 2025, Jonathan Wakely wrote:
> On Tue, 15 Jul 2025 at 08:26, Tomasz Kaminski wrote:
> >
> >
> >
> > On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote:
> >>
> >> Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perh
On Tue, 15 Jul 2025, Tomasz Kaminski wrote:
> On Tue, Jul 15, 2025 at 5:51 AM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk only
> (since it impacts ABI)?
>
> In theory an Iterator that meets all semantic requirements of the
&
Tested on x86_64-pc-linux-gnu, does this look OK for trunk only
(since it impacts ABI)?
-- >8 --
LWG 3569 adjusted join_view's iterator to handle adapting
non-default-constructible (input) iterators by wrapping the
corresponding data member with std::optional, and we followed suit in
r13-2649-g7a
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
15? Not sure if this corner case is worth backporting any further.
Can we just use direct-list-initialization via {} instead of '= T()'
here? I wasn't sure so I went with the latter to more closely mirror
the standard.
-- >8
Hi,
On Thu, 22 May 2025, 1nfocalypse wrote:
> Implements Philox Engine (P2075R6) and associated tests.
>
> v2 corrects a multiline comment left in error in serialize.cc, and
> additionally corrects a bug hidden by said comment, where the stream was
> given the output of 'y()' instead of 'y', c
On Tue, 8 Jul 2025, Jonathan Wakely wrote:
> We should not use the std::fill optimization for trivial types during
> constant evaluation, because we need to begin the lifetime of all
> objects, even trivially default constructible ones.
>
> This fixes a bug that Clang diagnosed:
>
> include/c++/
On Wed, 9 Jul 2025, Jonathan Wakely wrote:
> Similar to the previous commit that made is_integral_v<__int128>
> unconditionally true, this makes is_floating_point_v<__float128>
> unconditionally true. With the new extended floating-point types in
> C++23 (std::float64_t etc.) it seems unhelpful fo
On Wed, 9 Jul 2025, Jonathan Wakely wrote:
> Since LWG 3828 (included in C++23) implementations are allowed to have
> extended integer types that are wider than intmax_t. This means we no
> longer have to make is_integral_v<__int128> false for strict -std=c++23
> mode, removing the confusing incon
On Thu, 3 Jul 2025, Jason Merrill wrote:
> On 7/2/25 7:58 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk?
> >
> > -- >8 --
> >
> > Here the flag -fno-delete-null-pointer-checks ca
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
-- >8 --
In r15-4555-gf191c830154565 we proactively implemented the initial
proposed resolution for LWG 4166 which was later revealed to be
insufficient, since we must also require equality_comparable of the
underlying iterators befor
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
Here the flag -fno-delete-null-pointer-checks causes the trivial address
comparison in
inline int a, b;
static_assert(&a != &b);
to be rejected as non-constant because with the flag we can't assume
such
On Wed, 2 Jul 2025, Jonathan Wakely wrote:
> On Wed, 2 Jul 2025 at 15:29, Patrick Palka wrote:
> >
> >
> > On Wed, 11 Jun 2025, Jonathan Wakely wrote:
> >
> > > As suggested by Jason, this makes all __normal_iterator operators into
> > > friends so
On Mon, 9 Jun 2025, Jeremy Rifkin wrote:
> Hi,
> This fixes PR c/82134 which concerns gcc emitting an incorrect unused
> result diagnostic for empty types. This diagnostic is emitted from
> tree-cfg.cc because of a couple code paths which attempt to avoid
> copying empty types, resulting in GIMPLE
On Wed, 11 Jun 2025, Jonathan Wakely wrote:
> As suggested by Jason, this makes all __normal_iterator operators into
> friends so they can be found by ADL and don't need to be separately
> exported in module std.
>
> The operator<=> comparing two iterators of the same type is removed
> entirely
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Btw, any thoughts on PR105611 which reports std::shift_left/right's use
of the three-parameter version of ranges::next (on legacy iterators) is
sketchy? Should we define a three-parameter std::__next analog for
legacy iterators and use t
On Fri, 27 Jun 2025, Jonathan Wakely wrote:
> On 27/06/25 14:53 +0100, Jonathan Wakely wrote:
> > On 26/06/25 23:12 -0400, Patrick Palka wrote:
> > > On Thu, 26 Jun 2025, Patrick Palka wrote:
> > >
> > > > PR libstdc++/100795
On Fri, 27 Jun 2025, Jonathan Wakely wrote:
> On 26/06/25 22:25 -0400, Patrick Palka wrote:
> > PR libstdc++/100795
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/ranges_algo.h (__detail::__find_if_not_n): New,
> > based on the stl_a
On Fri, 27 Jun 2025, Jonathan Wakely wrote:
> On 26/06/25 22:25 -0400, Patrick Palka wrote:
> > PR libstdc++/100795
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/ranges_algo.h (__detail::__move_merge): New,
> > based on the stl_a
On Thu, 26 Jun 2025, Patrick Palka wrote:
> PR libstdc++/100795
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_algo.h (__sample_fn::operator()):
> Reimplement the forward_iterator branch directly.
> * testsuite/25_algorithms/sample/c
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
15/14?
-- >8 --
PR libstdc++/120789
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__unique_fn::operator()): Use
ranges::iter_move(iter) instead of std::move(*iter).
* testsuite/25_algo
PR libstdc++/120789
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__remove_if_fn::operator()): Use
ranges::iter_move(iter) instead of std::move(*iter).
* testsuite/25_algorithms/remove_if/120789.cc: New test.
---
libstdc++-v3/include/bits/ranges_algo.h
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__introselect): New,
based on the stl_algo.h implementation.
(nth_element_fn::operator()): Reimplement in terms of the above.
* testsuite/25_algorithms/nth_element/constrain
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__sample_fn::operator()):
Reimplement the forward_iterator branch directly.
* testsuite/25_algorithms/sample/constrained.cc (test02):
New test.
---
libstdc++-v3/include/bits/ranges_a
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__find_if_not_n): New,
based on the stl_algo.h implementation.
(__detail::__stable_partition_adaptive): Likewise.
(__stable_partition_fn::operator()): Reimplement in terms o
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (shuffle_fn::operator()):
Reimplement directly.
* testsuite/25_algorithms/shuffle/constrained.cc (test02):
---
libstdc++-v3/include/bits/ranges_algo.h | 58 ++-
.../25_a
PR libstdc++/100795
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__detail::__move_merge): New,
based on the stl_algo.h implementation.
(__detail::__merge_sort_loop): Likewise.
(__detail::__chunk_insertion_sort): Likewise.
(__detail::__merge
As with the previous patch, this patch reimplements ranges::sort
directly instead of incorrectly forwarding to std::sort. In addition to
the compatibility changes listed in the previous patch we also:
- use ranges::iter_swap instead of std::iter_swap
- use ranges::move_backward instead of std
As with the previous patch, this patch reimplements ranges::inplace_merge
directly instead of incorrectly forwarding to std::inplace_merge. In
addition to the compatibility changes listed in the previous patch we
also:
- explicitly cast the difference type (which can be an integer class) to
ranges::push_heap, ranges::pop_heap, ranges::make_heap and
ranges::sort_heap are currently defined in terms of the corresponding
STL-style algorithms, but this is incorrect because the STL-style
algorithms rely on the legacy iterator system, and so misbehave when
passed a narrowly C++20 random acce
On Tue, 24 Jun 2025, Jonathan Wakely wrote:
> On Tue, 24 Jun 2025 at 03:20, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > When checking __is_complete_or_unbounded on a reference to
On Tue, 24 Jun 2025, Jason Merrill wrote:
> On 6/23/25 5:41 PM, Nathaniel Shead wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
> >
> > -- >8 --
> >
> > We were erroring because the TEMPLATE_DECL of the existing partial
> > specialisation has an undeduced return ty
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
When checking __is_complete_or_unbounded on a reference to incomplete
type, we overeagerly try to instantiate/complete the referenced type
which besides being unnecessary may also produce a -Wsfinae-incomplete
warning (added in
On Sat, 14 Jun 2025, Jason Merrill wrote:
> On 6/13/25 1:36 PM, Patrick Palka wrote:
> > On Fri, 13 Jun 2025, Jason Merrill wrote:
> >
> > > Tested x86_64-pc-linux-gnu, any comments? Bikeshedding?
> > >
> > > -- 8< --
> > >
> >
On Fri, 13 Jun 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, any comments? Bikeshedding?
>
> -- 8< --
>
> We already error about a type definition causing a concept check to change
> value, but it would be useful to diagnose this for other SFINAE contexts as
> well; the memoization p
On Fri, 13 Jun 2025, Tomasz Kaminski wrote:
>
>
> On Fri, Jun 13, 2025 at 3:54 PM Patrick Palka wrote:
> On Fri, 13 Jun 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Thu, Jun 12, 2025 at 9:05 PM Patrick Palka
> wrote:
>
On Fri, 13 Jun 2025, Tomasz Kaminski wrote:
>
>
> On Thu, Jun 12, 2025 at 9:05 PM Patrick Palka wrote:
> On Thu, 12 Jun 2025, Patrick Palka wrote:
>
> > On Thu, 12 Jun 2025, Jonathan Wakely wrote:
> >
> > >
> > >
&
On Thu, 12 Jun 2025, Patrick Palka wrote:
> On Thu, 12 Jun 2025, Jonathan Wakely wrote:
>
> >
> >
> > On Thu, 12 Jun 2025, 16:56 Patrick Palka, wrote:
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > I'm sure
On Thu, 12 Jun 2025, Patrick Palka wrote:
> Changes in v4:
> * Don't pass a projection function throughout the helpers, instead
> create a pass a composite predicate via __make_comp_proj.
>
> -- >8 --
>
> ranges::push_heap, ranges::pop_heap, ranges::make_hea
On Thu, 12 Jun 2025, Patrick Palka wrote:
> Changes in v4:
> * Don't pass a projection function throughout the helpers, instead
> create a pass a composite predicate via __make_comp_proj.
>
> -- >8 --
>
> As with the previous patch, this patch reimplements ra
On Thu, 12 Jun 2025, Jonathan Wakely wrote:
>
>
> On Thu, 12 Jun 2025, 16:56 Patrick Palka, wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> I'm sure if introducing a new overload is preferable to
> introducing a constexpr
On Thu, 12 Jun 2025, Patrick Palka wrote:
> On Thu, 12 Jun 2025, Patrick Palka wrote:
>
> > On Thu, 12 Jun 2025, Tomasz Kaminski wrote:
> >
> > >
> > >
> > >
> > > On Thu, Jun 12, 2025 at 5:06 PM Patrick Palka wrote:
Changes in v4:
* Don't pass a projection function throughout the helpers, instead
create a pass a composite predicate via __make_comp_proj.
-- >8 --
As with the previous patch, this patch reimplements ranges::sort
directly instead of incorrectly forwarding to std::sort. In addition to
the
Changes in v4:
* Don't pass a projection function throughout the helpers, instead
create a pass a composite predicate via __make_comp_proj.
-- >8 --
ranges::push_heap, ranges::pop_heap, ranges::make_heap and
ranges::sort_heap are currently defined in terms of the corresponding
STL-style alg
On Thu, 12 Jun 2025, Patrick Palka wrote:
> On Thu, 12 Jun 2025, Tomasz Kaminski wrote:
>
> >
> >
> >
> > On Thu, Jun 12, 2025 at 5:06 PM Patrick Palka wrote:
> > On Wed, 11 Jun 2025, Tomasz Kaminski wrote:
> >
> > >
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
I'm sure if introducing a new overload is preferable to
introducing a constexpr if branch in the existing overload.
-- >8 --
When composing a comparator/predicate and projection function, if both
are stateless (and default constructible
On Thu, 12 Jun 2025, Tomasz Kaminski wrote:
>
>
>
> On Thu, Jun 12, 2025 at 5:06 PM Patrick Palka wrote:
> On Wed, 11 Jun 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Tue, Jun 10, 2025 at 3:08 AM Patrick Palka
> wrote:
>
On Thu, 12 Jun 2025, Patrick Palka wrote:
> On Wed, 11 Jun 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Tue, Jun 10, 2025 at 3:08 AM Patrick Palka wrote:
> > As with the previous patch, this patch reimplements ranges::sort
> > directly inst
On Wed, 11 Jun 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Jun 10, 2025 at 3:08 AM Patrick Palka wrote:
> As with the previous patch, this patch reimplements ranges::sort
> directly instead of incorrectly forwarding to std::sort. In addition to
> the com
On Wed, 11 Jun 2025, Tomasz Kaminski wrote:
>
>
> On Wed, Jun 11, 2025 at 1:56 PM Jonathan Wakely wrote:
> On Wed, 11 Jun 2025 at 12:42, Tomasz Kaminski
> wrote:
> >
> >
> >
> > On Tue, Jun 10,
On Mon, 9 Jun 2025, Patrick Palka wrote:
> As with the previous patch, this patch reimplements ranges::sort
> directly instead of incorrectly forwarding to std::sort. In addition to
> the compatibility changes listed in the previous patch we also:
>
> - use ranges::iter_swap
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
This patch makes these integer-class types structural types by
public-izing their data memberss so that they could be used as NTTP
types. I don't think the standard requires this, but it seems
like a useful extension.
libstdc+
Hi,
On Thu, 22 May 2025, 1nfocalypse wrote:
> Implements Philox Engine (P2075R6) and associated tests.
>
> v2 corrects a multiline comment left in error in serialize.cc, and
> additionally corrects a bug hidden by said comment, where the stream was
> given the output of 'y()' instead of 'y', c
As with the previous patch, this patch reimplements ranges::sort
directly instead of incorrectly forwarding to std::sort. In addition to
the compatibility changes listed in the previous patch we also:
- use ranges::iter_swap instead of std::iter_swap
- use ranges::move_backward instead of std
ranges::push_heap, ranges::pop_heap, ranges::make_heap and
ranges::sort_heap are currently defined in terms of the corresponding
STL-style algorithms, but this is incorrect because the STL-style
algorithms rely on the legacy iterator system, and so misbehave when
passed a narrowly C++20 random acce
On Fri, 6 Jun 2025, Jonathan Wakely wrote:
> Including behaves differently depending on whether you have
> the TBB headers installed or not. Without them installed, the modules
> tests PASS, but with TBB headers installed they FAIL with:
>
> gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: inte
Built on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
release branches?
-- >8 --
Jonathan noticed this flag isn't documented in the manual.
gcc/ChangeLog:
* doc/invoke.texi: Add -fconcepts-diagnostics-depth.
---
gcc/doc/invoke.texi | 8 +++-
1 file changed, 7 insert
On Wed, 5 Mar 2025, Patrick Palka wrote:
> On Wed, 5 Mar 2025, Patrick Palka wrote:
>
> > On Thu, 24 Oct 2024, Jonathan Wakely wrote:
> >
> > > On Wed, 9 Oct 2024 at 14:02, Patrick Palka wrote:
> > > >
> > > > On Mon, 7 Oct 2024, Patrick Palka
On Wed, 21 May 2025, Jason Merrill wrote:
> On 5/20/25 11:28 AM, Patrick Palka wrote:
> > On Mon, 19 May 2025, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk/15/14?
> >
> > Whoop
I think we also need to export the ::pmr version?
On Wed, Jun 4, 2025 at 10:44 AM Tomasz Kamiński wrote:
>
> PR libstdc++/119152
>
> libstdc++-v3/ChangeLog:
>
> * src/c++23/std.cc.in (std::indirect) [__cpp_lib_indirect]
> (std::polymorphic) [__cpp_lib_polymorphic]: Export.
On Tue, May 27, 2025 at 8:37 AM Tomasz Kamiński wrote:
>
> From: Jonathan Wakely
>
> This patch implements C++26 std::polymorphic as specified in P3019 with
> amendment to move assignment from LWG 4251.
>
> The implementation always allocate stored object on the heap. The manager
> function (_M_m
On Sat, 31 May 2025, Nathaniel Shead wrote:
> On Fri, May 30, 2025 at 11:10:08AM -0400, Patrick Palka wrote:
> > On Fri, 30 May 2025, Patrick Palka wrote:
> >
> > > On Fri, 30 May 2025, Nathaniel Shead wrote:
> > >
> > > > On Wed, May 28,
On Thu, 29 May 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> Various places were still making assumptions that we could get to the 'this'
> capture through current_class_ref in a lambda op(), which is incorrect for
> an explicit object op().
>
>
On Fri, 30 May 2025, Patrick Palka wrote:
> On Fri, 30 May 2025, Nathaniel Shead wrote:
>
> > On Wed, May 28, 2025 at 02:14:06PM -0400, Patrick Palka wrote:
> > > On Tue, 27 May 2025, Nathaniel Shead wrote:
> > >
> > > > On Wed, Nov 27, 202
On Fri, 30 May 2025, Nathaniel Shead wrote:
> On Wed, May 28, 2025 at 02:14:06PM -0400, Patrick Palka wrote:
> > On Tue, 27 May 2025, Nathaniel Shead wrote:
> >
> > > On Wed, Nov 27, 2024 at 11:45:40AM -0500, Patrick Palka wrote:
> > > > On Fr
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
-- >8 --
... for consistency with the other standard container adaptors
(stack, queue, etc).
libstdc++-v3/ChangeLog:
* include/std/flat_set (_Flat_set_impl::operator==):
Define in terms of ==, not std::equal.
---
li
On Thu, 29 May 2025, Tomasz Kaminski wrote:
>
>
> On Thu, May 29, 2025 at 4:37 PM Tomasz Kaminski wrote:
>
>
> On Thu, May 29, 2025 at 3:56 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
>
> -- >8 --
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
-- >8 --
Instead of effectively doing a zipped comparison of the keys and values,
compare them separately to leverage the underlying containers' optimized
equality implementations.
libstdc++-v3/ChangeLog:
* include/std/flat_
std::erase_if for flat_map / flat_multimap is implemented via
ranges::erase_if over a zip_view of the keys and values, the value_type
of which is a tuple, but the given predicate needs to be called with a
pair. So use a projection to convert the tuple into the corresponding
pair type.
PR
Change in this version:
* Add test using an integer-class distance type, based on views::iota.
-- >8 --
This implements ranges::starts_with and ranges::ends_with from the C++23
paper P1659R3. The logic of these algorithms is contained in an _S_impl
member function that takes optional size par
On Sat, 24 May 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk/15?
LGTM FWIW
>
> -- >8 --
>
> When emitting a primary module interface, we must re-stream any TU-local
> entities that we saw in a partition. This patch adds the missing
> members fr
On Thu, 22 May 2025, Nathaniel Shead wrote:
> This patch series adds support for streaming some internal declarations
> in C++20 modules that we previously would ICE on.
I like this patch series a lot, thanks for working on it! I can't
approve but it looks pretty good to me.
>
> The series h
On Tue, 27 May 2025, Nathaniel Shead wrote:
> On Wed, Nov 27, 2024 at 11:45:40AM -0500, Patrick Palka wrote:
> > On Fri, 8 Nov 2024, Nathaniel Shead wrote:
> >
> > > Does this approach seem reasonable? I'm pretty sure that the way I've
> > > handled
On Wed, 28 May 2025, Tomasz Kaminski wrote:
>
>
> On Wed, May 28, 2025 at 4:53 PM Patrick Palka wrote:
> On Wed, 28 May 2025, Tomasz Kamiński wrote:
>
> > This patch adjust the passing of parameters for the
> move_only_function,
> > copyable_
On Wed, 28 May 2025, Tomasz Kamiński wrote:
> This patch adjust the passing of parameters for the move_only_function,
> copyable_function and function_ref. For types that are declared as being
> passed
> by value in signature template argument, the are passed by value to the
> invoker,
they
>
>
>
> On Tue, May 20, 2025 at 6:32 PM Patrick Palka wrote:
> On Tue, 20 May 2025, Tomasz Kaminski wrote:
>
> > I think I do not have any more suggestions for cases to check, so the
> impl LGTM.
>
> It's cool how many optimizations
On Wed, 28 May 2025, Tomasz Kaminski wrote:
>
>
> On Tue, May 27, 2025 at 7:08 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
>
> The 'volatile' issue from that PR Will be fixed in a separate patch as
>
On the 13 branch and older, C++ >= 20 tests need an explicit dg-options
directive specifying the -std flag, otherwise they won't run by default.
PR libstdc++/112490
libstdc++-v3/ChangeLog:
* testsuite/24_iterators/const_iterator/112490.cc: Add
dg-options directive.
---
l
On Tue, 27 May 2025, Patrick Palka wrote:
> On Tue, 27 May 2025, David Malcolm wrote:
>
> > On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > > On 4/14/25 9:57 AM, Jason Merrill wrote:
> > > > On 1/9/25 10:00 PM, Jason Merrill wrote:
> > &g
On Tue, 27 May 2025, David Malcolm wrote:
> On Fri, 2025-05-23 at 16:58 -0400, Jason Merrill wrote:
> > On 4/14/25 9:57 AM, Jason Merrill wrote:
> > > On 1/9/25 10:00 PM, Jason Merrill wrote:
> > > > Tested x86_64-pc-linux-gnu. Is the diagnostic.h change OK for
> > > > trunk?
> > >
> > > Ping?
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
The 'volatile' issue from that PR Will be fixed in a separate patch as
operator[] isn't the only operation that's affected.
-- >8 --
The const lvalue operator[] overload wasn't properly forwarding the key
type to the generic overload
On Wed, 21 May 2025, Jonathan Wakely wrote:
> Because this constructor delegates to vector(a) the object has been
> fully constructed and the destructor will run if an exception happens.
> That means we need to set _M_finish == _M_start so that the destructor
> doesn't try to destroy any elements.
Changes in v6:
* dispatch to starts_with for the bidi haystack + random access
needle case too
Changes in v5:
* dispatch to starts_with for the both-bidi/common range case
Changes in v4:
* optimize the both-bidi/common ranges case, as suggested by
Tomasz
* add tests for that code
On Tue, 20 May 2025, Tomasz Kaminski wrote:
> I think I do not have any more suggestions for cases to check, so the impl
> LGTM.
It's cool how many optimizations we came up with for this algorithm :)
>
> On Tue, May 20, 2025 at 4:33 PM Patrick Palka wrote:
>
On Mon, 19 May 2025, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk/15/14?
Whoops, CI reports I missed a testsuite adjustment expecting an
additional error in other/default13.C, which seems reasonable. Here's
an updated pa
On Tue, 20 May 2025, Patrick Palka wrote:
> Changes in v5:
> * dispatch to starts_with for the both-bidi/common range case
Forgot to mention:
And for a bidi common haystack, prefer iterating forward instead of
backward if the needle is at least half the size of the haystack,
>
>
Changes in v5:
* dispatch to starts_with for the both-bidi/common range case
Changes in v4:
* optimize the both-bidi/common ranges case, as suggested by
Tomasz
* add tests for that code path
Changes in v3:
* Use the forward_range code path for a (non-sized) bidirectional
haystack,
Changes in V4:
* optimize the both-directional/common ranges case, as suggested by
Tomasz
* add tests for that code path
Changes in v3:
* Use the forward_range code path for a (non-sized) bidirectional
haystack, since it's slightly fewer increments/decrements
overall.
* Fix wro
On Tue, 20 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 6:06 PM Patrick Palka wrote:
> On Mon, 19 May 2025, Patrick Palka wrote:
>
> > Changes in v3:
> > * Use the forward_range code path for a (non-sized) bidirectional
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/15/14?
-- >8 --
Here we declare f twice, first ordinarily and then using a dependent
alias template. Due to alias template transparency these logically
declare the same overload. But now the function type of f, which
On Mon, 19 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 9:59 AM Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 6:47 AM Patrick Palka wrote:
> I would appreciate a short explanation on the approach being put here,
> in the message. Like passi
On Mon, 19 May 2025, Patrick Palka wrote:
> Changes in v3:
> * Use the forward_range code path for a (non-sized) bidirectional
> haystack, since it's slightly fewer increments/decrements
> overall.
> * Fix wrong iter_difference_t cast in starts_with.
>
> Ch
On Mon, 19 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 19, 2025 at 4:11 PM Patrick Palka wrote:
> Changes in v2:
> Addressed Tomasz's review comments, namely:
> * Added explicit iter_difference_t casts
> * Made _S_impl member pri
Changes in v3:
* Use the forward_range code path for a (non-sized) bidirectional
haystack, since it's slightly fewer increments/decrements
overall.
* Fix wrong iter_difference_t cast in starts_with.
Changes in v2:
Addressed Tomasz's review comments, namely:
* Added explicit iter_di
1 - 100 of 1489 matches
Mail list logo
