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
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 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, 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_
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 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, 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 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, 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, 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 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 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 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 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 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
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 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
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 Mon, 21 Apr 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
> -- 8< --
>
> While working on PR119162 it occurred to me that it would be simpler to
> detect the problem of a value referring to a heap allocation if we stopped
> setting TREE_STATIC on them so they natura
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
On Mon, 28 Apr 2025, Jonathan Wakely wrote:
> On Mon, 28 Apr 2025 at 14:59, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
> >
> > -- >8 --
> >
> > These std::erase_if overloads were wrongly implemented as hi
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/15?
-- >8 --
These std::erase_if overloads were wrongly implemented as hidden
friends, visible only via ADL, so erase_if(x) would work but not
std::erase_if(x).
PR libstdc++/119427
libstdc++-v3/ChangeLog:
* include/std/
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
Tested on x86_64-pc-linux-gnu, pushed to trunk and the 15 release branch with
pre-approval from Jonathan and Jakub.
-- >8 --
This non-standard optimization breaks real-world code that expects the
result of std::projected to always (be a class type and) have a value_type
member, which isn't true f
On Wed, 16 Apr 2025, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> If we already gave an error while parsing a function, we don't also need to
> try to explain what's wrong with it when we later try to use it in a
> constant-expression. In the new testca
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk and later 14?
-- >8 --
When remapping existing specializations of a hidden template friend from
a previous declaration to the new definition, we must remap only those
specializations that match this new definition, but
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk and perhaps 14?
-- >8 --
Our constraint recursion diagnostics are not ideal because they
usually show the atom with an uninstantiated parameter mapping, e.g
concepts-recursive-sat5.C:6:41: error: satisfaction of atomi
be good with either.
On Wed, 9 Apr 2025, Patrick Palka wrote:
> On Wed, 9 Apr 2025, Patrick Palka wrote:
>
> > On Wed, 5 Mar 2025, Jason Merrill wrote:
> >
> > > On 3/5/25 10:13 AM, Patrick Palka wrote:
> > > > On Tue, 4 Mar 2025, Jaso
On Sat, 12 Apr 2025, Jason Merrill wrote:
> On 4/11/25 4:36 PM, Patrick Palka wrote:
> > Boostrapped and regtested on x86_64-pc-linux- gnu, does this look OK
> > for GCC 15 perhaps?
> >
> > -- >8 --
> >
> > This patch improves upon r15-6052-g12de1942a0a
On Sat, 12 Apr 2025, Jason Merrill wrote:
> On 4/11/25 4:36 PM, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > GCC 15 perhaps?
> >
> > -- >8 --
> >
> > Here checking
> >
> >static
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
GCC 15 perhaps?
-- >8 --
Here checking
static_assert(0 == big_calc());
takes twice as much time as
constexpr int ret = big_calc();
static_assert(0 == ret);
ultimately because in the former, we first constexpr evalu
Boostrapped and regtested on x86_64-pc-linux- gnu, does this look OK
for GCC 15 perhaps?
-- >8 --
This patch improves upon r15-6052-g12de1942a0a673 by performing prvalue
folding with mce_false rather than mce_unknown when it's safe to do so
(i.e. the caller passed ff_mce_false), so that we can al
On Wed, 9 Apr 2025, Patrick Palka wrote:
> On Wed, 5 Mar 2025, Jason Merrill wrote:
>
> > On 3/5/25 10:13 AM, Patrick Palka wrote:
> > > On Tue, 4 Mar 2025, Jason Merrill wrote:
> > >
> > > > On 3/4/25 2:49 PM, Patrick Palka wrote:
> > > &g
On Wed, 5 Mar 2025, Jason Merrill wrote:
> On 3/5/25 10:13 AM, Patrick Palka wrote:
> > 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, do
Bootstrap and regtest running on x86_64-pc-linux-gnu, does this look
OK for trunk/14 if successful?
On a similar note, as a small optimization in deduction_guides_for I
think we can replace the lookup_add loop with a single call to
lookup_add, but I'll leave that for GCC 16.
-- >8 --
With inheri
On Wed, 2 Apr 2025, Tomasz Kamiński wrote:
> This patch implements part P2372R3 that specified debug (escaped)
> format for the stings and characters sequecenes. This include both
> handling of the '?' formatt specifier and set_debug_format member.
>
> To indicate partial support we define __glib
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/14?
-- >8 --
It was proposed in PR112490 to also adjust basic_const_iterator's friend
operator-(sent, iter) overload alongside the r15-7757-g4342c50ca84ae5
adjustments to its comparison operators, but we lacked a concrete
testcase demonst
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
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for the 14 branch?
-- >8 --
In GCC 14 we fixed PR116567 in a more conservative way that doesn't
distinguish between the two kinds of deferred substitutions, and we
instead ICE from get_innermost_template_args due to TMPL_PARMS_D
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Here we substitute into the inner lambda twice, first during default
argument substitution for the outer template parameters, then during
that for the inner template parameters.
For the second testcase (whic
On Fri, 4 Apr 2025, Patrick Palka wrote:
> 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.
> > >
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk? This isn't a regression and potentially impacts
C++17 code, but it also makes alias CTAD unusable for our std::variant
currently.
-- >8 --
Here during maybe_dependent_member_ref (as part of CTAD rewriting
for the var
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
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
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, 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 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, 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
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
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, 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.
>
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
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
Here during maybe_dependent_member_ref for accepted_type<_Up>, we
correctly don't strip the typedef because it's a complex one (its
defaulted template parameter isn't used in its definition) and so
we recurse to consider its corresponding TYPE_DECL.
We then incorrectly decide to not rewrite this u
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
On Tue, 5 Nov 2024, Jason Merrill wrote:
> On 10/17/24 1:10 PM, Patrick Palka wrote:
> > On Thu, 17 Oct 2024, Patrick Palka wrote:
> >
> > > On Tue, 15 Oct 2024, Patrick Palka wrote:
> > >
> > > > On Tue, 15 Oct 2024, Patrick Palka wrote:
> &g
On Wed, 26 Mar 2025, Tomasz Kamiński wrote:
> As pointed out by Hewill Kang (reporter) in the issue, checking if iterator
> of the incoming range satisfies __cpp17_input_iterator, may still lead
> to hard errors inside of insert_range for iterators that satisfies
> that concept, but specialize ite
On Mon, 24 Mar 2025, Tomasz Kamiński wrote:
> These patch add check to verify if common range iterators satisfies
> Cpp17LegacyIterator requirements (__detail::__cpp17_input_iterator),
> before invoking overloads of insert that accepts two iterators.
> As such overloads existed before c++20 iterat
On Mon, 24 Mar 2025, Tomasz Kamiński wrote:
> These patch add check to verify if common range iterators satisfies
> Cpp17LegacyIterator requirements (__detail::__cpp17_input_iterator),
> before invoking overloads of insert that accepts two iterators.
> As such overloads existed before c++20 iterat
On Mon, 24 Mar 2025, Jonathan Wakely wrote:
> Unlike insert_range and assign_range, the append_range function does not
> have a precondition that the range doesn't overlap *this. That means we
> need to avoid relocating the existing elements until after copying from
> the range. This means I need
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
Complex alias templates (and their dependent specializations) use
structural equality because we want to treat them as transparent in some
contexts but not others. Structural-ness however wasn't being preser
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
14/13/12 (since it was reported against GCC 12)? This old regression is
already fixed on trunk by r15-123 which contains this change.
-- >8 --
Here we ICE during instantiation of the dependently scoped template
friend
te
Fixed by r15-123 (specifically the change to set processing_template_decl
when tsubsting UNBOUND_CLASS_TEMPLATE).
PR c++/119378
gcc/testsuite/ChangeLog:
* g++.dg/template/friend85.C: New test.
---
gcc/testsuite/g++.dg/template/friend85.C | 16
1 file changed, 16
On Tue, 18 Mar 2025, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14?
>
> -- >8 --
> This ICE appeared with the removal of NON_DEPENDENT_EXPR. Previously
> skip_simple_arithmetic would get NON_DEPENDENT_EXPR> and
> since NON_DEPENDENT_EXPR is neither BINARY_
On Mon, 17 Mar 2025, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/14/13?
>
> -- >8 --
> r12-1094 mentions that adding the assert didn't lead to any regressions
> in the testsuite, but this test case demonstrates that we can reach it
> with valid code.
>
> He
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk/backports?
-- >8 --
This is just the member function pointer version of PR c++/105848,
wherein our non-dependent call pruning may cause us to not mark an
otherwise unused function pointer template argument as used.
1 - 100 of 1422 matches
Mail list logo
