Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
-- >8 --
This std::expected friend operator== is prone to constraint recursion
after CWG 2369 for the same reason as basic_const_iterator's comparison
operators were before the r15-7757-g4342c50ca84ae5 workaround. This
patch works ar
On Fri, 18 Apr 2025, Jason Merrill wrote:
> limit_bad_template_recursion currently avoids immediate instantiation of
> templates from uses in an already ill-formed instantiation, but we still can
> get unnecessary recursive instantiation in pending_templates if the
> instantiation was queued befor
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/15/14?
-- >8 --
In r15-123 and r14-11434 we unconditionally set processing_template_decl
when substituting the context of an UNBOUND_CLASS_TEMPLATE, in order to
handle instantiation of the dependently scoped friend dec
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
- Use __builtin_unreachable to suppress a false-positive "control
reaches end of non-void function" warning in the recursive lambda
(which the existing tests failed to notice since test01 wasn't
being called at runtime)
-
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
The original implementation was accidentally based off of an older
revision of the paper, P2542R7 instead of R8. As far as I can tell
the only semantic change in the final revision is the relaxed
constraints on the iterator's
On Wed, 19 Feb 2025, Jonathan Wakely wrote:
> On Tue, 18 Feb 2025 at 04:11, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> > -- >8 --
> >
> > The original implementation was accidentally based off of a
On Wed, 19 Feb 2025, Patrick Palka wrote:
> On Wed, 19 Feb 2025, Jonathan Wakely wrote:
>
> > On Tue, 18 Feb 2025 at 04:11, Patrick Palka wrote:
> > >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> > >
> > > -- >8 --
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
Even though iterator is a reserved macro name, we can't use it as the
name of this implementation detail type since it could introduce name
lookup ambiguity in valid code, e.g.
struct A { using iterator = void; }
struct B :
On Wed, 19 Feb 2025, Marek Polacek wrote:
> I suppose it's safer to leave this for GCC 16, but anyway:
>
> Bootstrapped/regtested on x86_64-pc-linux-gnu.
>
> -- >8 --
> Since r10-7718 the attached tests produce an ICE in verify_address:
>
> error: constant not recomputed when 'ADDR_EXPR' chan
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> 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 immediate
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> 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/C
On Fri, 28 Feb 2025, Patrick Palka wrote:
> On Thu, 27 Feb 2025, Jonathan Wakely wrote:
>
> > 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* w
On Fri, 28 Feb 2025, Jonathan Wakely wrote:
> On 28/02/25 16:27 -0500, Patrick Palka wrote:
> > On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> >
> > > The specification for std::ranges::iter_move apparently requires us to
> > > handle types which do not sati
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14? Not sure about backporting further given the original fix seems
harmless.
-- >8 --
It turns out the reason the behavior of this testcase changed after CWG
2369 is because validity of the substituted return type is now che
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
-- >8 --
When a generic lambda calls an overload set containing an iobj member
function we speculatively capture 'this'. We need to do the same
for an xobj member function.
PR c++/119038
gcc/cp/ChangeLog:
On Fri, 7 Mar 2025, Tomasz Kamiński wrote:
> Add missing move_constructible && regular_invocable constrains on functor
> type,
> and is_object on functor result type for invocations of views::zip_transform
> without range arguments.
>
> PR libstdc++/38
>
> libstdc++-v3/ChangeLog:
>
On Fri, 7 Mar 2025, Jonathan Wakely wrote:
>
>
> On Fri, 7 Mar 2025 at 15:05, Tomasz Kamiński wrote:
> Add missing move_constructible && regular_invocable constrains on
> functor type,
> for invocations of `views::zip_transform` without range arguments.
>
> libstdc++-v3/Chang
On Fri, 28 Feb 2025, Giuseppe D'Angelo wrote:
> Hello,
>
> On 27/02/2025 15:34, Jonathan Wakely wrote:
> > On 26/02/25 17:27 +0100, Giuseppe D'Angelo wrote:
> > > On 26/02/2025 16:33, Giuseppe D'Angelo wrote:
> > > > Whops, sorry, missed this sub-thread (while replying to the other one).
> > > >
On Sun, 2 Mar 2025, xxie-xd wrote:
> * Patrick Palka [2025-02-28 10:37:37]:
>
> > Hi,
> >
> > On Fri, 28 Feb 2025, Da Xie wrote:
> >
> > > This bug comes from a missing check when a function declaration has a
> > > late-specified retur
On Sun, 2 Mar 2025, Da Xie wrote:
> Add check for constrained auto type specifier in function declaration or
> function type declaration with trailing return type. Issue error if such
> usage is detected.
>
> Test file renamed, and added a new test for type declaration.
>
> Successfully bootstra
On Thu, Mar 6, 2025 at 8:53 AM Jonathan Wakely wrote:
>
> LWG 4172 was approved in Hagenberg, February 2025, fixing
> std::unique_lock and std::shared_lock to work correctly for
> self-move-assignment.
>
> Our std::shared_lock was already doing the right thing (contradicting
> the standard) so jus
On Thu, Mar 6, 2025 at 6:33 AM Jonathan Wakely wrote:
>
> This destructor declaration serves no purpose, as pointed out by LWG
> 3903 which was approved at Varna, June 2023.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/span (span::~span): Remove, as per LWG 3903.
LGTM
> ---
>
> Tested x
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> libstdc++-v3/ChangeLog:
>
> * include/
On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
>
> On Tue, Mar 11, 2025 at 5:04 PM Patrick Palka wrote:
> On Tue, 11 Mar 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Mon, Mar 10, 2025 at 11:28 PM Patrick Palka
> wrote:
>
Tested on x86_64-pc-linux-gnu, does this look OK for stage 1?
-- >8 --
The PR68942 fix used the tf_conv flag to disable mark_used when
substituting a FUNCTION_DECL callee of an ADL-enabled call. In this
slightly more elaborate testcase, we end up prematurely calling
mark_used anyway on the FUNCT
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
14?
-- >8 --
Here for
using RCI = reverse_iterator::iterator>>
static_assert(std::totally_ordered);
we effectively need to check the requirement
requires (RCI x) { x RELOP x; } for each RELOP in {<, >, <=, >=}
which
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> On Thu, 27 Feb 2025 at 20:52, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > 14?
>
> OK for both.
Thanks.
>
> Do we want a library issue for this? The
Hi,
On Fri, 28 Feb 2025, Da Xie wrote:
> This bug comes from a missing check when a function declaration has a
> late-specified return type and a constrained auto type specifier. By
> adding such a check, we can catch such uses and diagnose them as errors.
>
> Successfully bootstrapped and regre
On Thu, 27 Feb 2025, Jonathan Wakely wrote:
> 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::_
Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 14 after
a while?
-- >8 --
The type tuple> is clearly copy/move constructible, but for
reasons that are not yet completely understood checking this triggers
constraint recursion with our C++20 tuple implementation (and not the
C++17
On Thu, 13 Mar 2025, Ville Voutilainen wrote:
> On Thu, 13 Mar 2025 at 23:16, Ville Voutilainen
> wrote:
> >
> > On Thu, 13 Mar 2025 at 23:03, Patrick Palka wrote:
> > > + // Defined as a template to work around PR libstdc++/116440.
> > > + templ
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/version.def (ranges_to_input): Define.
* include/bits/version.h: Regenerate.
* include/std/ranges (ranges::to_input_view): Define for C++26.
(views::__detai
On Thu, 13 Mar 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk, and 14 after
> a while?
>
> -- >8 --
>
> The type tuple> is clearly copy/move constructible, but for
> reasons that are not yet completely understood checking
On Tue, 4 Mar 2025, Patrick Palka wrote:
> On Sun, 2 Mar 2025, Da Xie wrote:
>
> > Add check for constrained auto type specifier in function declaration or
> > function type declaration with trailing return type. Issue error if such
> > usage is detected.
> >
>
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 wrote:
> >
> > > Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
> > > This doesn't see
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 wrote:
> > >
> > > > Tested on x86_64-pc-linux-gnu, doe
On Tue, 4 Mar 2025, Jason Merrill wrote:
> On 3/4/25 2:49 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > for trunk/14?
> >
> > -- >8 --
> >
> > In the three-parameter version of satisfy_declaratio
On Mon, 17 Feb 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> -- >8 --
>
> - Use __builtin_unreachable to suppress a false-positive "control
> reaches end of non-void function" warning in the recursive lambda
>
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk/14?
-- >8 --
In the three-parameter version of satisfy_declaration_constraints, when
't' isn't the most general template, then 't' won't correspond with
'args' after we augment the latter via add_outermost_template_arg
On Wed, 12 Mar 2025, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
> perhaps 13?
>
> N.B. the use of a constrained auto instead of a separate static_assert
> in the testcase is unfortunate but I opted for local consistency for
&g
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
perhaps 13?
N.B. the use of a constrained auto instead of a separate static_assert
in the testcase is unfortunate but I opted for local consistency for
now.
-- >8 --
Unlike for span and empty_view, the range_reference_t of
ref_vie
On Wed, 12 Mar 2025, Patrick Palka wrote:
> On Wed, 12 Mar 2025, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14 and
> > perhaps 13?
> >
> > N.B. the use of a constrained auto instead of a separate static_assert
> >
On Thu, 13 Feb 2025, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> Here we have:
>
> template
> struct X{
> T val;
> decltype(auto) value(){
> return (val);
> }
> };
>
> where the return type of value should be
On Tue, 4 Feb 2025, Patrick Palka wrote:
> On Tue, 4 Feb 2025, Patrick Palka wrote:
>
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
> > 14 (after a long while)?
> >
> > -- >8 --
> >
> > LWG 4027 effectively makes th
On Sat, 15 Feb 2025, Jonathan Wakely wrote:
> These should have been unsigned, but the static assertions are only in
> the public std::bit_ceil and std::bit_width functions, not the internal
> __bit_ceil and __bit_width ones.
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/simd
On Sun, 16 Feb 2025, Giuseppe D'Angelo wrote:
> Hello,
>
> the attached patch implements the C++26 papers that add `constexpr` to the
> specialized memory algorithms (the uninitialized_* family). Tested on x86-64
> Linux.
>
> Thank you,
> --
> Giuseppe D'Angelo
>
> Subject: [PATCH] libstdc++:
Tested on x86_64-pc-linxu-gnu, pushed to trunk as obvious.
-- >8 --
PR libstdc++/118083
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h
(ranges::__access::__possibly_const_range): Mention LWG 4027.
---
libstdc++-v3/include/bits/ranges_base.h | 2 ++
1 file changed,
On Tue, 25 Feb 2025, Jonathan Wakely wrote:
> On Thu, 20 Feb 2025 at 16:23, Patrick Palka wrote:
> >
> > On Sun, 16 Feb 2025, Giuseppe D'Angelo wrote:
> >
> > > Hello,
> > >
> > > the attached patch implements the C++26 papers that add `const
On Fri, 21 Feb 2025, Nathaniel Shead wrote:
> After seeing PR c++/118964 I'm coming back around to this [1] patch
> series, since it appears that this can cause errors on otherwise valid
> code by instantiations coming into module purview that reference
> TU-local entities.
>
> [1]: https://gcc.g
On Fri, 4 Apr 2025, Nathaniel Shead wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?
>
> -- >8 --
>
> Modules streaming walks decls multiple times, first as a non-streaming
> walk to find dependencies, and then later to actually emit the decls.
> The first walk needs to
On Fri, 4 Apr 2025, Patrick Palka wrote:
> On Thu, 3 Apr 2025, Jason Merrill wrote:
>
> > On 4/2/25 2:28 PM, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk/14?
> >
> > OK for 14.
>
Here the implicit use of 'this' in inner.size() template argument was
being rejected despite P2280R4 relaxations, due to the special *this
handling in the INDIRECT_REF case of potential_constant_expression_1.
This handling was originally added by r196737 as part of the PR56481,
and it seems obsole
On Thu, 3 Apr 2025, Jason Merrill wrote:
> On 4/2/25 2:28 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk/14?
>
> OK for 14.
>
> For 15, what happens if we remove that error entirely? Do we still give
flat_set::emplace (and flat_multiset) currently unconditionally
constructs an object outside of the container, but if we're passed
a value_type object we can and should avoid that.
PR libstdc++/119620
libstdc++-v3/ChangeLog:
* include/std/flat_set (_Flat_set_impl::_M_try_emplace)
On Fri, 4 Apr 2025, Tomasz Kaminski wrote:
>
>
> On Fri, Apr 4, 2025 at 6:07 PM Tomasz Kaminski wrote:
>
>
> On Fri, Apr 4, 2025 at 5:50 PM Patrick Palka wrote:
> flat_set::emplace (and flat_multiset) currently unconditionally
> constructs an object outsi
On Fri, 4 Apr 2025, Patrick Palka wrote:
> On Fri, 4 Apr 2025, Tomasz Kaminski wrote:
>
> >
> >
> > On Fri, Apr 4, 2025 at 6:07 PM Tomasz Kaminski wrote:
> >
> >
> > On Fri, Apr 4, 2025 at 5:50 PM Patrick Palka wrote:
> >
On Fri, 28 Mar 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, initially with extra checking to make sure that
> indeed nothing got saved from a namespace level.
>
> This isn't a regression, but a 20% speedup for a simple change is pretty
> attractive; what do people think about this cha
Bootstrapped and regtested on x86_64-pc-linux, does this look
OK for trunk/14?
-- >8 --
The testcase in this PR uses 2.5x more memory and 6x more compile
time ever since r14-5979 which implements P2280R4. This is because
our speculative constexpr folding now does a lot more work trying to
fold
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/14?
-- >8 --
Here we wrongly reject the requires-expression requirement at parse time
due to the use of the constraint variable 't' within a template argument
(an evaluated context). Fix this simply by refining the "u
On Fri, 4 Apr 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> Since r10-7441 we set processing_template_decl in a requires-expression so
> that we can use tsubst_expr to evaluate the requirements, but that confuses
> lambdas terribly; begin_lambda_typ
On Fri, 4 Apr 2025, Jason Merrill wrote:
> On 4/4/25 4:35 PM, Patrick Palka wrote:
> > On Fri, 4 Apr 2025, Jason Merrill wrote:
> >
> > > Tested x86_64-pc-linux-gnu, applying to trunk.
> > >
> > > -- 8< --
> > >
> > > Since r10-7
Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK
for trunk/15/14?
-- >8 --
Here unification of P=Wrap::type, A=Wrap::type wrongly
succeeds ever since r14-4112 which made the RECORD_TYPE case of unify
no longer recurse into template arguments for non-primary templates
(since th
On Mon, 12 May 2025, Tomasz Kamiński wrote:
> This patch implements C++26 copyable_function as specified in P2548R6.
> It also implements LWG 4255 that adjust move_only_function so constructing
> from empty copyable_function, produces empty functor. This falls from
> existing checks, after special
On Tue, 6 May 2025, Tomasz Kaminski wrote:
>
>
> On Mon, May 5, 2025 at 8:50 PM Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
>
> This LGTM.
> Out of curiosity, would declaring them as members also fix the issue?
Ah yes i
On Mon, 12 May 2025, Tomasz Kamiński wrote:
> Based on the provision in C++26 [func.wrap.general] p2 this patch adjust the
> generic
> move_only_function(_Fn&&) constructor, such that when _Fn refers to selected
> move_only_function instantiations, the ownership of the target object is
> direclt
On Mon, 12 May 2025, Tomasz Kamiński wrote:
> The file now includes copyable_function in addition to
> move_only_function.
>
> PR libstdc++/119125
>
> libstdc++-v3/ChangeLog:
> * include/bits/move_only_function.h: Move to...
> * include/bits/funcwrap.h: ...here.
> * doc/d
On Thu, 15 May 2025, Tomasz Kamiński wrote:
> This patch implements C++26 function_ref as specified in P0792R14,
> with correction for constraints for constructor accepting nontype_t
> parameter from LWG 4256.
>
> As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
> change
On Wed, 14 May 2025, Jason Merrill wrote:
> On 5/12/25 7:53 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK
> > for trunk/15/14?
> >
> > -- >8 --
> >
> > Here unification of P=Wrap::type, A=Wrap::typ
On Wed, 14 May 2025, Patrick Palka wrote:
> On Wed, 14 May 2025, Jason Merrill wrote:
>
> > On 5/12/25 7:53 PM, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86-64-pc-linux-gnu, does this look OK
> > > for trunk/15/14?
> > >
> > >
On Wed, 14 May 2025, Tomasz Kamiński wrote:
> This patch implements C++26 function_ref as specified in P0792R14,
> with correction for constraints for constructor accepting nontype_t
> parameter from LWG 4256.
>
> As function_ref may store a pointer to the const object, __Ptrs::_M_obj is
> chan
On Wed, 14 May 2025, Patrick Palka wrote:
> On Wed, 14 May 2025, Jason Merrill wrote:
>
> > On 5/14/25 2:44 PM, Patrick Palka wrote:
> > > On Wed, 14 May 2025, Patrick Palka wrote:
> > >
> > > > On Wed, 14 May 2025, Jason Merrill wrote:
> > > &
On Wed, 14 May 2025, Jason Merrill wrote:
> On 5/14/25 2:44 PM, Patrick Palka wrote:
> > On Wed, 14 May 2025, Patrick Palka wrote:
> >
> > > On Wed, 14 May 2025, Jason Merrill wrote:
> > >
> > > > On 5/12/25 7:53 PM, Patrick Palka wrote:
> >
On Tue, 13 May 2025, Ville Voutilainen wrote:
> On Tue, 13 May 2025 at 23:34, Jason Merrill wrote:
> >
> > On 5/13/25 4:29 PM, Ville Voutilainen wrote:
> > > On Tue, 13 May 2025 at 23:23, Jason Merrill wrote:
> > >>>/* Check that the return and argument types are sane before
> > >>>
On Thu, 8 May 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> This tweak to CWG2369 has gotten more discussion lately in CWG, including in
> P3606. In those discussions, it occurred to me that having the check depend
> on whether a class has been ins
On Wed, 14 May 2025, Tomasz Kaminski wrote:
>
>
> On Wed, May 14, 2025 at 9:41 AM Tomasz Kaminski wrote:
>
>
> On Tue, May 13, 2025 at 11:16 PM Patrick Palka wrote:
> On Mon, 12 May 2025, Tomasz Kamiński wrote:
>
> > Based on the provision in C++
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 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,
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,
>
>
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
>
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 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, 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:
>
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
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__starts_with_fn, starts_with):
Define.
(__ends_with_fn, ends_with): Define.
* include/bits/version.def (ranges_starts_ends_with): Define.
On Mon, 19 May 2025, 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 passing -1 as means of saying, size not know.
>
> Tested on x86_
Changes in v2:
Addressed Tomasz's review comments, namely:
* Added explicit iter_difference_t casts
* Made _S_impl member private
* Optimized sized bidirectional case of ends_with
* Rearranged control flow of starts_with::_S_impl
Still left to do:
* Add tests for integer-class types
On Mon, 19 May 2025, Patrick Palka wrote:
> Changes in v2:
> Addressed Tomasz's review comments, namely:
> * Added explicit iter_difference_t casts
> * Made _S_impl member private
> * Optimized sized bidirectional case of ends_with
> * Rearranged control flow
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
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
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 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
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 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?
>
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
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
For a complex alias template-id, dependent_alias_template_spec_p returns
true if any template argument of the template-id is dependent. This
predicate indicates that substitution into the template-id may behave
differently with respect to SFINAE than substitution into the expanded
alias, and so th
During partial ordering, we want to look through dependent alias
template specializations within template arguments and otherwise
treat them as opaque in other contexts (see e.g. r7-7116-g0c942f3edab108
and r11-7011-g6e0a231a4aa240). To that end template_args_equal was
given a partial_order flag t
On Sat, May 13, 2023 at 7:26 PM Bernhard Reutner-Fischer via
Gcc-patches wrote:
>
> From: Bernhard Reutner-Fischer
>
> gcc/cp/ChangeLog:
>
> * call.cc (promoted_arithmetic_type_p): Use _P defines from tree.h.
> (build_conditional_expr): Ditto.
> (convert_like_internal): Di
1101 - 1200 of 2575 matches
Mail list logo
