On Fri, 9 Jun 2023, Jonathan Wakely via Libstdc++ wrote:
> Tested powerpc64le-linux. Pushed to trunk.
>
> This makes sense to backport after some soak time on trunk.
>
> -- >8 --
>
> As reported in PR libstdc++/110167, std::to_array compiles extremely
> slowly for very large arrays. It needs
On Sun, 2 Apr 2023, Ken Matsui via Gcc-patches wrote:
> This patch gets std::is_function to dispatch to new built-in trait
> __is_function.
For std::is_function and other predicate-like type traits, I think we also
want to make the corresponding variable template is_function_v directly
use the
When defining a previously declared class template, we neglect to set
TPARMS_PRIMARY_TEMPLATE for the in-scope template parameters, which the
class members go on to inherit, and so the members' DECL_TEMPLATE_PARMS
will have empty TPARMS_PRIMARY_TEMPLATE at those levels as well. This
causes us to
On Wed, 7 Jun 2023, Jason Merrill wrote:
> On 6/6/23 14:29, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > In the second testcase of PR110122, during regeneration of the generic
> > lambda with V=Bar{},
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
In the second testcase of PR110122, during regeneration of the generic
lambda with V=Bar{}, substitution followed by coerce_template_parms for
A's template argument naturally yields a copy of V in terms of
Here when substituting the injected class name A during regeneration of
the lambda, we find ourselves in lookup_template_class for A with
V=_ZTAXtl3BarEE (i.e. the template parameter object for Foo{}). The
call to coerce_template_parms within then undesirably tries to make a copy
of this class
On Thu, 1 Jun 2023, Patrick Palka wrote:
> 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
Bootstrapped and regtested on x86_64-pc-linu-xgnu, does this look OK for trunk?
-- >8 --
Here we notice the 'this' conversion for the call f() is bad, so
we correctly defer instantiating it, but we end up never adding it to
'bad_fns' since missing_conversion_p for it returns false (its only
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
All uses of in_template_function besides the one in cp_make_fname_decl
seem like they could be generalized to apply to all template contexts,
not just function templates. To that end this patch replaces the
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for trunk?
-- >8 --
r10-7815-gaa576f2a860c82 added special hashing for TEMPLATE_TEMPLATE_PARM
since non-lowered ttps had TYPE_CANONICAL but level lowered ttps did not.
But this is no longer the case ever since
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
The check for a non-template member function of a class template in
is_specialization_of_friend is overbroad, and accidentally holds for a
non-template hidden friend too, which causes the predicate to return
Due to level/depth mismatches between the template parameters of a level
lowered ttp and the original ttp, the ttp comparison check added by
r14-418-g0bc2a1dc327af9 never actually holds outside of erroneous cases.
Moreover, it'd be good to cache the overall TEMPLATE_TEMPLATE_PARM
instead of just
On Wed, May 3, 2023 at 9:50 AM Patrick Palka wrote:
>
> This patch makes us coerce the arguments of a variable template-id ahead
> of time, as we do for other template-ids, which allows us to immediately
> diagnose template parameter/argument kind mismatches and arity mismatches.
>
>
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):
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
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
On Tue, May 23, 2023 at 3:42 PM Ken Matsui via Gcc-patches
wrote:
>
> Since the type_traits header is a C++11 header file, using can be used instead
> of typedef. This patch provides more readability, especially for long type
> names.
>
> libstdc++-v3/ChangeLog:
>
> *
On Fri, 19 May 2023, Patrick Palka wrote:
> This implements noexcept-expr mangling (and demangling) as per the
> Itanium ABI.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
> look OK for trunk?
>
> PR c++/70790
>
> gcc/cp/ChangeLog:
>
> * mangle.cc
This implements noexcept-expr mangling (and demangling) as per the
Itanium ABI.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this
look OK for trunk?
PR c++/70790
gcc/cp/ChangeLog:
* mangle.cc (write_expression): Handle NOEXCEPT_EXPR.
libiberty/ChangeLog:
*
Avoid performing two norm_cache lookups during normalization of a
concept-id by allocating inserting a norm_entry* before rather than
after the fact, which is simpler and faster.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
*
lookup_and_finish_template_variable calls convert_from_reference, which
means for a variable template-id of reference type the function returns
an INDIRECT_REF instead of the bare VAR_DECL. But the downstream logic
of two callers, tsubst_qualified_id and finish_class_member_access_expr,
expect a
On Fri, 12 May 2023, Ken Matsui via Libstdc++ wrote:
> It appears that GCC 13 has been released, but I am wondering if there
> are any issues preventing this patch from being merged yet. Can you
> provide any information on this?
Thanks for the reminder, I pushed this to trunk just now
add_list_candidates has logic to reject designated initialization of a
non-aggregate type, but this is inadvertendly being suppressed if the type
has a list constructor due to the order of case analysis, which in the
below testcase leads to us incorrectly treating the list initializer as
an
On Mon, May 15, 2023 at 11:43 AM Jakub Jelinek wrote:
>
> On Mon, May 15, 2023 at 11:41:46AM -0400, Jason Merrill via Gcc-patches wrote:
> > On 5/15/23 11:24, Patrick Palka wrote:
> > > This adds the feature-test macro for PR0849R8, as per
> > > https://github.com/cplusplus/CWG/issues/281.
> > >
This adds the feature-test macro for PR0849R8, as per
https://github.com/cplusplus/CWG/issues/281.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/13?
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_auto_cast
for C++23.
On Wed, 3 May 2023, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> -- 8< --
>
> We try to cache the result of reduce_template_parm_level so that when we
> reduce the same parm multiple times we get the same result, but this wasn't
> working for
Hi Martin,
On Fri, May 12, 2023 at 12:13 PM Martin Jambor wrote:
>
> Hello Patrick,
>
> On Wed, May 03 2023, Patrick Palka via Gcc-patches wrote:
> >
> [...]
> >
> > Subject: [PATCH] c++: potentiality of templated memfn call [PR109480]
> >
> > Here
This rewrites the testcase for PR109752 to make it simpler and more
robust (i.e. no longer dependent on r13-4035-gc41bbfcaf9d6ef).
PR c++/109752
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr109752.C: Rename to ...
* g++.dg/cpp2a/concepts-complete4.C: ... this.
I noticed only after the fact that the new testcase template/function2.C
(from r14-708-gc3afdb8ba8f183) is just a subset of ext/visibility/anon8.C,
so let's get rid of it.
PR c++/83258
gcc/testsuite/ChangeLog:
* g++.dg/ext/visibility/anon8.C: Mention PR83258.
*
On Thu, 11 May 2023, Patrick Palka wrote:
> r13-2701-g7107ea6fb933f1 made us correctly accept 'mutable' member
> accesses during constexpr evaluation of objects constructed during that
> evaluation, while continuing to reject such accesses for constexpr
> objects constructed outside of that
r13-2701-g7107ea6fb933f1 made us correctly accept 'mutable' member
accesses during constexpr evaluation of objects constructed during that
evaluation, while continuing to reject such accesses for constexpr
objects constructed outside of that evaluation, by considering the
On Fri, 5 May 2023, Jonathan Wakely wrote:
>
>
> On Fri, 5 May 2023 at 10:43, Florian Weimer wrote:
> * Jonathan Wakely via Libstdc:
>
> > We could use strtod for a single-threaded target (i.e.
> > !defined(_GLIBCXX_HAS_GTHREADS) by changing the global locale using
> >
We accept this testcase since r13-806-g221acd67ca50f8.
PR c++/103807
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-targ1.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/lambda-targ1.C | 11 +++
1 file changed, 11 insertions(+)
create mode 100644
On Wed, 10 May 2023, Jason Merrill wrote:
> On 5/10/23 11:36, Patrick Palka wrote:
> > r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
> > in convert_nontype_argument for C++17, but we need to also remove the one
> > in convert_nontype_argument_function for sake of the
r8-1253-g3d2e25a240c711 removed the template argument linkage requirement
in convert_nontype_argument for C++17, but we need to also remove the one
in convert_nontype_argument_function for sake of the first and third test
case which we incorrectly reject (in C++17/20 mode).
And in
On Tue, 9 May 2023, Patrick Palka wrote:
> After diagnosing and recovering from unstable satisfaction, it's
> possible to evaluate an atom for the first time noisily rather than
> quietly. The satisfaction cache tries to handle this situation
> gracefully, but apparently not gracefully enough:
When processing a noexcept-spec from a nested class after completion of
the outer class (since a noexcept-spec is a complete-class context), we
pass to noexcept_override_late_checks the outer class type instead of
the nested class type, which leads to bogus errors in the below test.
This patch
After diagnosing and recovering from unstable satisfaction, it's
possible to evaluate an atom for the first time noisily rather than
quietly. The satisfaction cache tries to handle this situation
gracefully, but apparently not gracefully enough: we inserted an empty
slot in the cache, and left it
On Fri, 5 May 2023, Patrick Palka wrote:
> Here we're neglecting to propagate parenthesized-ness when the member
> access expression (this->m) resolves to a static member (and thus
> finish_class_member_access_expr yields a VAR_DECL instead of a
> COMPONENT_REF).
>
> Bootstrapped and regtested
Here we're neglecting to propagate parenthesized-ness when the member
access expression (this->m) resolves to a static member (and thus
finish_class_member_access_expr yields a VAR_DECL instead of a
COMPONENT_REF).
Bootstrapped and regtested on x86_64-pc-linux-gnu, does look OK for
trunk?
It seems DR 2256 permitted goto to cross the initialization of a
trivially initialized object with a non-trivial destructor. We
already supported this as an -fpermissive extension, so this patch
just makes us unconditionally support this.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does
This extends the PR93107 fix, which made us do resolve_nondeduced_context
on the elements of an initializer list during auto deduction, to happen
for CTAD as well.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/106214
PR c++/93107
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/85979
gcc/cp/ChangeLog:
* cxx-pretty-print.cc (cxx_pretty_printer::unary_expression)
: Consider ALIGNOF_EXPR_STD_P.
* error.cc (dump_expr) : Likewise.
gcc/testsuite/ChangeLog:
* Harden some tree accessor macros and fix some incorrect uses of
PLACEHOLDER_TYPE_CONSTRAINTS.
* Use strip_innermost_template_args in outer_template_args.
* Add !processing_template_decl early exit tests to some dependence
predicates.
gcc/cp/ChangeLog:
* cp-tree.h
On Fri, Apr 28, 2023 at 8:54 AM Patrick Palka wrote:
>
> On Thu, 27 Apr 2023, Patrick Palka wrote:
>
> > On Thu, Apr 27, 2023 at 4:46 PM Patrick Palka wrote:
> > >
> > > Now that with r14-11-g2245459c85a3f4 made us coerce the template
> > > arguments of a bound ttp again after level-lowering,
On Wed, 3 May 2023, Jason Merrill wrote:
> On 5/2/23 15:53, Patrick Palka wrote:
> > on Tue, 2 May 2023, Patrick Palka wrote:
> >
> > > On Tue, 2 May 2023, Jason Merrill wrote:
> > >
> > > > On 5/1/23 15:59, Patrick Palka wrote:
> > > > > Here we're incorrectly deeming the templated call a.g()
On Wed, 3 May 2023, Patrick Palka wrote:
> This patch makes us coerce the arguments of a variable template-id ahead
> of time, as we do for other template-ids, which allows us to immediately
> diagnose template parameter/argument kind mismatches and arity mismatches.
>
> Unfortunately this
This patch makes us coerce the arguments of a variable template-id ahead
of time, as we do for other template-ids, which allows us to immediately
diagnose template parameter/argument kind mismatches and arity mismatches.
Unfortunately this causes a regression in cpp1z/constexpr-if20.C: coercing
constraints_satisfied_p already carefully checks dependence of template
arguments before proceeding with satisfaction, so the dependence check
in instantiate_alias_template is unnecessary and overly conservative.
Getting rid of it allows us to check satisfaction ahead of time in more
cases as in
on Tue, 2 May 2023, Patrick Palka wrote:
> On Tue, 2 May 2023, Jason Merrill wrote:
>
> > On 5/1/23 15:59, Patrick Palka wrote:
> > > Here we're incorrectly deeming the templated call a.g() inside b's
> > > initializer as potentially constant, despite g being non-constexpr,
> > > which leads to
On Tue, 2 May 2023, Jason Merrill wrote:
> On 5/1/23 15:59, Patrick Palka wrote:
> > Here we're incorrectly deeming the templated call a.g() inside b's
> > initializer as potentially constant, despite g being non-constexpr,
> > which leads to us wastefully instantiating the initializer ahead of
The PR109666 fix r14-386-g07c52d1eec967 incidentally also fixes this PR.
PR c++/109506
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/nsdmi-template26.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/nsdmi-template26.C | 22 +++
1 file changed, 22 insertions(+)
create mode
Here we're incorrectly deeming the templated call a.g() inside b's
initializer as potentially constant, despite g being non-constexpr,
which leads to us wastefully instantiating the initializer ahead of time
and triggering a bug in access checking deferral (which will get fixed
in the subsequent
enforce_access currently inspects processing_template_decl to determine
whether to defer the given access check until instantiation time. But
using this flag is unreliable because it gets cleared during e.g.
non-dependent initializer folding, and can lead to premature access
check failures as in
On Fri, 28 Apr 2023, Patrick Palka wrote:
> On Fri, 28 Apr 2023, Patrick Palka wrote:
>
> > After mechanically replacing RESULT_DECL within a constexpr call result
> > (for sake of RVO), we can in some cases simplify the call result
> > further.
> >
> > In the below testcase the result of get()
On Fri, 28 Apr 2023, Patrick Palka wrote:
> After mechanically replacing RESULT_DECL within a constexpr call result
> (for sake of RVO), we can in some cases simplify the call result
> further.
>
> In the below testcase the result of get() during evaluation of a's
> initializer is the
After mechanically replacing RESULT_DECL within a constexpr call result
(for sake of RVO), we can in some cases simplify the call result
further.
In the below testcase the result of get() during evaluation of a's
initializer is the self-referential CONSTRUCTOR:
{._M_p=(char *) &._M_local_buf}
On Thu, 27 Apr 2023, Patrick Palka wrote:
> On Thu, Apr 27, 2023 at 4:46 PM Patrick Palka wrote:
> >
> > Now that with r14-11-g2245459c85a3f4 made us coerce the template
> > arguments of a bound ttp again after level-lowering, this unfortunately
> > causes a crash from
On Thu, Apr 27, 2023 at 4:46 PM Patrick Palka wrote:
>
> Now that with r14-11-g2245459c85a3f4 made us coerce the template
> arguments of a bound ttp again after level-lowering, this unfortunately
> causes a crash from coerce_template_args_for_ttp in the below testcase.
>
> During the
Now that with r14-11-g2245459c85a3f4 made us coerce the template
arguments of a bound ttp again after level-lowering, this unfortunately
causes a crash from coerce_template_args_for_ttp in the below testcase.
During the level-lowering substitution T=int into the bound ttp TT
as part of
The testcase from this PR fails to link when -fchecking=2 with the error:
/usr/bin/ld: /tmp/ccpHiXEY.o: in function `bar::bar()':
...: undefined reference to `foo::foo()'
ultimately because we end up instantiating the NSDMI for bar::alloc_
from the template context func1 for which
On Thu, Sep 1, 2022 at 2:40 PM Jason Merrill wrote:
>
> On 8/31/22 17:15, Patrick Palka wrote:
> > This introduces an early exit test to most_specialized_partial_spec for
> > the common case where we have no partial specializations, which allows
> > us to avoid some unnecessary work. In passing,
Does this look OK for wwwdocs?
---
htdocs/gcc-13/changes.html | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 7b64b2e5..191d0a4d 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
On Sat, 18 Mar 2023, Patrick Palka wrote:
> On Fri, 17 Mar 2023, Jason Merrill via Gcc-patches wrote:
>
> > Tested x86_64-pc-linux-gnu, applying to trunk.
> >
> > -- 8< --
> >
> > When a lambda refers to a constant local variable in the enclosing scope, we
> > tentatively capture it, but if we
On Mon, 24 Apr 2023, Patrick Palka wrote:
> This patch fixes sign bit propagation when right-shifting a negative
> __max_diff_type value by more than one, a bug which our test coverage
> failed to uncover until r14-159-g03cebd304955a6 fixed the front end's
> 'signed typedef-name' handling (which
On Sun, 23 Apr 2023, Jonathan Wakely wrote:
>
>
> On Saturday, April 22, 2023, Jakub Jelinek wrote:
> > On Sat, Apr 22, 2023 at 11:30:24AM +0800, haochen.jiang via Gcc-patches
> > wrote:
> >> On Linux/x86_64,
> >>
> >> 03cebd304955a6b9c5607e09312d77f1307cc98e is the first bad commit
> >>
This patch makes these integer-class type structural types by changing
their private data members into public ones, which allows them to be
used as NTTP types. I'm not sure if this is required by the standard
but it seems handy.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
This patch fixes sign bit propagation when right-shifting a negative
__max_diff_type value by more than one, a bug which our test coverage
failed to uncover until r14-159-g03cebd304955a6 fixed the front end's
'signed typedef-name' handling (which is a non-standard extension to
the language
On Sun, 4 Dec 2022, Patrick Palka wrote:
> The functions strip_array_types, is_typedef_decl, typedef_variant_p,
> cp_type_quals and cp_expr_location are used throughout the C++ frontend
> including in some fairly hot parts (e.g. in the tsubst routines and
> cp_walk_subtree) and they're small
On Mon, 5 Dec 2022, Jason Merrill wrote:
> On 12/5/22 06:09, Prathamesh Kulkarni wrote:
> > On Mon, 5 Dec 2022 at 09:51, Patrick Palka via Gcc-patches
> > wrote:
> > >
> > > These functions currently repeatedly dereference tp during the subtree
> > > w
On Thu, 20 Apr 2023, Patrick Palka wrote:
> 1. Now that we no longer substitute the constraints of an auto, we can
>get rid of the infinite recursion loop breaker during level lowering
>of a constrained auto and we can also use the TEMPLATE_PARM_DESCENDANTS
>cache in this case.
> 2.
1. Now that we no longer substitute the constraints of an auto, we can
get rid of the infinite recursion loop breaker during level lowering
of a constrained auto and we can also use the TEMPLATE_PARM_DESCENDANTS
cache in this case.
2. Don't bother recursing when level lowering a
This patch makes us use a TREE_VEC instead of TREE_LIST to represent the
trailing arguments of a variadic built-in trait. These built-ins are
typically passed a simple pack expansion as the second argument, e.g.
__is_constructible(T, Ts...)
so the main benefit of this representation change
If we have a TREE_VEC of types that we want to strip of typedefs, we
unintuitively need to call strip_typedefs_expr instead of strip_typedefs
since only strip_typedefs_expr handles TREE_VEC, and it also dispatches
to strip_typedefs when given a type. But this seems backwards: arguably
On Wed, 19 Apr 2023, Patrick Palka wrote:
> Aside from correcting how try_class_unification copies multi-dimensional
> 'targs', r13-377-g3e948d645bc908 also made it ggc_free this copy as an
> optimization. But this is potentially wrong since the call to unify
> within might've captured the args
Aside from correcting how try_class_unification copies multi-dimensional
'targs', r13-377-g3e948d645bc908 also made it ggc_free this copy as an
optimization. But this is potentially wrong since the call to unify
within might've captured the args in persistent memory such as the
satisfaction cache
On Tue, 18 Apr 2023, Jason Merrill wrote:
> On 4/11/23 10:21, Patrick Palka wrote:
> > On Thu, 26 Jan 2023, Jason Merrill wrote:
> >
> > > On 1/25/23 15:35, Patrick Palka wrote:
> > > > On Tue, 17 Jan 2023, Jason Merrill wrote:
> > > >
> >
On Wed, Apr 5, 2023 at 1:36 PM Andrew Pinski wrote:
>
> On Wed, Apr 5, 2023 at 10:32 AM Patrick Palka via Gcc-patches
> wrote:
> >
> > On Wed, 5 Apr 2023, Patrick Palka wrote:
> >
> > > r13-6098-g46711ff8e60d64 made make_typename_type no longer ignore
>
Here when level lowering the bound ttp TT via the
substitution T=C, we're neglecting to canonicalize (and therefore strip
of simple typedefs) the resulting template arguments {A} before
determining its new canonical type via hash table lookup. This leads to
an a hash mismatch ICE for the two
This C++23 paper fixes a bug in these views when adapting a certain kind
of non-forward range, and we treat it as a DR against C++20.
Tested on x86_64-pc-linux-gnu, does this look OK for GCC 13? This
is an ABI change for join_view so it'd be unsuitable for backporting
later I think :(
This patch also renames __cpp_lib_fold to __cpp_lib_ranges_fold
as per the current draft standard.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__cpp_lib_ranges_contains):
Define for C++23.
(__cpp_lib_ranges_iota): Likewise.
(__cpp_lib_ranges_find_last):
PR libstdc++/109525
libstdc++-v3/ChangeLog:
* include/std/ranges (views::_AsConst::operator()): Add
missing const to constant_range test.
* testsuite/std/ranges/adaptors/as_const/1.cc (test02):
Improve formatting. Adjust expected type of v2.
On Fri, 14 Apr 2023, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> PR libstdc++/108827
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value
> for C++23.
> * include/std/ranges
On Fri, 14 Apr 2023, Patrick Palka wrote:
> Using the CRTP idiom for this base class avoids bloating the size of a
> pipeline when adding distinct empty range adaptor closure objects to it,
> as detailed in section 4.1 of P2387R3.
>
> But it means we can no longer define its operator| overloads
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc++/108827
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value
for C++23.
* include/std/ranges (range_adaptor_closure): Define for C++23.
*
Using the CRTP idiom for this base class avoids bloating the size of a
pipeline when adding distinct empty range adaptor closure objects to it,
as detailed in section 4.1 of P2387R3.
But it means we can no longer define its operator| overloads as hidden
friends, since each instantiation of
On Fri, 14 Apr 2023, Jonathan Wakely wrote:
> On 14/04/23 00:00 -0400, Patrick Palka wrote:
> > This also implements the approved follow-up LWG issues 3765, 3766, 3769,
> > 3770, 3811, 3850, 3853, 3862 and 3872.
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
> >
> >
This also implements the approved follow-up LWG issues 3765, 3766, 3769,
3770, 3811, 3850, 3853, 3862 and 3872.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (const_iterator_t): Define for C++23.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h: Include for C++23.
(__cpp_lib_fold): Define for C++23.
(in_value_result): Likewise.
(__detail::__flipped): Likewise.
This moves down the definitions of the const range access CPOs to after
the definition of input_range in preparation for implementing P2287R4
which redefines these CPOs in a way that indirectly uses input_range.
tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
On Tue, Apr 11, 2023 at 11:12 AM Jonathan Wakely wrote:
>
> On Tue, 11 Apr 2023 at 15:59, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk perhaps?
>
> Yes, this is only for C++23 so OK for trunk now.
Yay thanks, pushed as
On Wed, Apr 12, 2023 at 11:04 AM Jonathan Wakely wrote:
>
> On Wed, 12 Apr 2023 at 14:45, Patrick Palka via Libstdc++
> wrote:
> >
> > This makes floating_from_chars.cc explicitly include all headers
> > that are used by the original fast_float amalgamation according to
> >
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc++/108291
libstdc++-v3/ChangeLog:
* include/std/ranges (chunk_by_view::_M_find_next): Generalize
parameter types of the predicate passed to adjacent_find.
(chunk_by_view::_M_find_prev):
This makes floating_from_chars.cc explicitly include all headers
that are used by the original fast_float amalgamation according to
r12-6647-gf5c8b82512f9d3, except:
1. since fast_float doesn't seem to use anything from it
2. since fast_float doesn't seem to use anything directly
from
Tested on x86_64-pc-linux-gnu, does this look OK for trunk perhaps?
libstdc++-v3/ChangeLog:
* include/std/ranges (__cpp_lib_ranges_enumerate): Define
for C++23.
(__detail::__range_with_movable_reference): Likewise.
(enumerate_view): Likewise.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/12?
libstdc++-v3/ChangeLog:
* include/std/ranges (lazy_split_view::_OuterIter::_OuterIter):
Propagate _M_trailing_empty in the const-converting constructor
as per LWG 3904.
*
On Thu, 26 Jan 2023, Jason Merrill wrote:
> On 1/25/23 15:35, Patrick Palka wrote:
> > On Tue, 17 Jan 2023, Jason Merrill wrote:
> >
> > > On 1/9/23 14:25, Patrick Palka via Gcc-patches wrote:
> > > > On Mon, 9 Jan 2023, Patrick Palka wrote:
> > > &
On Mon, 3 Apr 2023, Jason Merrill wrote:
> On 4/3/23 10:49, Patrick Palka wrote:
> > This testcase demonstrates we can legitimately enter satisfaction with
> > an ARGUMENT_PACK_SELECT argument, which is problematic because we can't
> > store such arguments in the satisfaction cache (or any other
On Wed, 5 Apr 2023, Patrick Palka wrote:
> r13-6098-g46711ff8e60d64 made make_typename_type no longer ignore
> non-types during the lookup, unless the TYPENAME_TYPE in question was
> followed by the :: scope resolution operator. But there is another
> exception to this rule: we need to ignore
r13-6098-g46711ff8e60d64 made make_typename_type no longer ignore
non-types during the lookup, unless the TYPENAME_TYPE in question was
followed by the :: scope resolution operator. But there is another
exception to this rule: we need to ignore non-types during the lookup
also if the
101 - 200 of 1377 matches
Mail list logo
