Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
The relationship between tsubst_copy_and_build and tsubst_copy (two of
the main template argument substitution routines for expression trees)
is rather hazy. The former is mostly a superset of the latter, wi
On Mon, 2 Oct 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> OK for trunk?
>
> -- >8 --
>
> The relationship between tsubst_copy_and_build and tsubst_copy (two of
> the main template argument substitution routines fo
On Tue, 3 Oct 2023, Jason Merrill wrote:
> On 10/3/23 08:41, Patrick Palka wrote:
> > On Mon, 2 Oct 2023, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> >
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
After the previous patch, we currently have two tsubst entry points
for expression trees: tsubst_copy_and_build and tsubst_expr. But the
latter is just a superset of the former that also handles statement
tr
This patch:
* changes splice_viable to move the non-viable candidates to the end
of the list instead of removing them outright
* makes tourney move the best candidate to the front of the candidate
list
* adjusts print_z_candidates to preserve our behavior of printing only
viable
With the previous improvements in place, we can easily extend our
deletedness diagnostic to note the other candidates:
deleted16.C: In function ‘int main()’:
deleted16.C:10:4: error: use of deleted function ‘void f(int)’
10 | f(0);
| ~^~~
deleted16.C:5:6: note: declared here
On Tue, 10 Oct 2023, Ken Matsui wrote:
> Since RID_MAX soon reaches 255 and all traits are used approximately once in
> a C++ translation unit, this patch instead uses only RID_TRAIT_EXPR and
> RID_TRAIT_TYPE for all traits and uses gperf to look up the specific trait.
Nice! This looks good to m
On Wed, 11 Oct 2023, Ken Matsui wrote:
> Since RID_MAX soon reaches 255 and all traits are used approximately once in
> a C++ translation unit, this patch instead uses only RID_TRAIT_EXPR and
> RID_TRAIT_TYPE for all traits and uses gperf to look up the specific trait.
>
> gcc/c-family/ChangeLog:
On Tue, 26 Sep 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> for trunk?
>
> -- >8 --
>
> This follow-up patch removes some more repetition of the type-dependent
On second thought there's no good reason to split the
s for
> built-in traits. Handle expression-yielding built-in traits.
> (cp_parser_trait): Handle cp_trait instead of enum rid.
> (cp_parser_simple_type_specifier): Remove all RID value cases
> for built-in traits. Handle type-yielding built-in traits.
> *
On Sun, 15 Oct 2023, Ken Matsui wrote:
> On Sun, Oct 15, 2023 at 1:43 PM Patrick Palka wrote:
> >
> > On Fri, 13 Oct 2023, Ken Matsui wrote:
> >
> > > Since RID_MAX soon reaches 255 and all built-in traits are used
> > > approximately
> > > once i
arser_simple_type_specifier): Remove all RID value cases
> for built-in traits. Handle type-yielding built-in traits.
>
> Co-authored-by: Patrick Palka
> Signed-off-by: Ken Matsui
> ---
> gcc/c-family/c-common.cc | 7 --
> gcc/c-family/c-common.h | 5 -
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch accepts the use of built-in trait identifiers when they are
> actually not used as traits. Specifically, we check if the subsequent token
> is '(' for ordinary built-in traits or is '<' only for the special
> __type_pack_element built-in trait.
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch sorts built-in traits alphabetically for better code
> readability.
Hmm, I'm not sure if we still want/need this change with this current
approach. IIUC gperf would sort the trait names when generating the
hash table code, and so we wanted a mo
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch optimizes the performance of the is_pointer trait by dispatching to
> the new __is_pointer built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/cpp_type_traits.h (__is_pointer): Use __is_pointer
> built-in trait.
> *
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch implements built-in trait for std::is_arithmetic.
>
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_arithmetic.
> * constraint.cc (diagnose_trait_expr): Handle CPTK_IS_ARITHMETIC.
> * semantics.cc (trait_expr_value): Likew
On Sun, 15 Oct 2023, Ken Matsui wrote:
> This patch optimizes the performance of the is_object trait by dispatching to
> the new __is_function and __is_reference built-in traits.
>
> libstdc++-v3/ChangeLog:
> * include/std/type_traits (is_object): Use __is_function and
> __is_referenc
On Mon, 16 Oct 2023, Ken Matsui wrote:
> On Mon, Oct 16, 2023 at 7:55 AM Patrick Palka wrote:
> >
> > On Sun, 15 Oct 2023, Ken Matsui wrote:
> >
> > > Since RID_MAX soon reaches 255 and all built-in traits are used
> > > approximately
> > > once i
On Mon, 16 Oct 2023, Ken Matsui wrote:
> On Mon, Oct 16, 2023 at 8:17 AM Patrick Palka wrote:
> >
> > On Sun, 15 Oct 2023, Ken Matsui wrote:
> >
> > > This patch sorts built-in traits alphabetically for better code
> > > readability.
> >
> >
Handle cp_trait instead of enum rid.
> (cp_parser_simple_type_specifier): Remove all RID value cases
> for built-in traits. Handle type-yielding built-in traits.
>
> Co-authored-by: Patrick Palka
> Signed-off-by: Ken Matsui
> ---
> gcc/c-family/c-common.cc |
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
-- >8 --
For a local variable initialized by a lambda:
auto f = []{};
The corresponding BLOCK_VARS contains the variable declaration first,
followed by the closure type declaration, consistent with the
syntactical
On Wed, 18 Oct 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
Note that this doesn't fix the other testcase in the PR, which doesn't use any
lambdas and which ICEs in the same way:
export module pr105
On Tue, 17 Oct 2023, Marek Polacek wrote:
> On Tue, Oct 17, 2023 at 04:49:52PM -0400, Jason Merrill wrote:
> > On 10/16/23 20:39, Marek Polacek wrote:
> > > On Sat, Oct 14, 2023 at 01:13:22AM -0400, Jason Merrill wrote:
> > > > On 10/13/23 14:53, Marek Polacek wrote:
> > > > > On Thu, Oct 12, 2023
On Thu, 19 Oct 2023, Jason Merrill wrote:
> On 10/12/23 14:49, Patrick Palka wrote:
> > On Tue, 26 Sep 2023, Patrick Palka wrote:
> >
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
> > > for trunk?
> > >
> > > -- &
On Tue, 3 Oct 2023, David Malcolm wrote:
> As mentioned in my Cauldron talk, this patch adds a call to
> diagnostic_show_locus to the "required from here" messages
> in print_instantiation_partial_context_line, so that e.g., rather
> than the rather mystifying:
>
> In file included from ../x86_64
Built on x86_64-pc-linux-gnu, pushed to trunk as obvious (hopefully).
-- >8 --
This patch removes stray NON_DEPENDENT_EXPR checks following the removal
of this tree code from the C++ FE. (Since this restores the build I
supppose it means the Rust FE never creates NON_DEPENDENT_EXPR trees in
the
n traits.
> (cp_parser_trait): Handle cp_trait instead of enum rid.
> (cp_parser_simple_type_specifier): Remove all RID value cases
> for built-in traits. Handle type-yielding built-in traits.
>
> Co-authored-by: Patrick Palka
> Signed-off-by: Ken Matsu
awesome that both testcases could
be fixed simultaneously after all :)
>
> nathan
>
> On 10/18/23 12:28, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > -- >8 --
> >
> > For a local va
On Fri, 20 Oct 2023, Ken Matsui wrote:
> This patch implements built-in trait for std::is_invocable.
Nice! My email client unfortunately ate my first review attempt, so
apologies for my brevity this time around.
> gcc/cp/ChangeLog:
>
> * cp-trait.def: Define __is_invocable.
> * con
On Fri, 20 Oct 2023, Patrick Palka wrote:
> On Fri, 20 Oct 2023, Ken Matsui wrote:
>
> > This patch implements built-in trait for std::is_invocable.
>
> Nice! My email client unfortunately ate my first review attempt, so
> apologies for my brevity this time around.
&g
On Fri, 20 Oct 2023, Patrick Palka wrote:
> On Fri, 20 Oct 2023, Patrick Palka wrote:
>
> > On Fri, 20 Oct 2023, Ken Matsui wrote:
> >
> > > This patch implements built-in trait for std::is_invocable.
> >
> > Nice! My email client unfortunately ate my
Bootstrapped and regtested on x86_64-pc-linux-gnu, pushed to
trunk as obvious.
-- >8 --
After r14-4796-g3e3d73ed5e85e7, tsubst_copy_and_build (now named
tsubst_expr) no longer dispatches to tsubst for type trees, and
callers have to do it themselves if appropriate. This patch makes
some overlook
On Sun, 22 Oct 2023, Ken Matsui wrote:
> Hi Patrick,
>
> There is an issue with the code in
> libstdc++-v3/include/bits/cpp_type_traits.h. Specifically, Clang 16
> does not accept the code, while Clang 17 does. Given that we aim to
> support the last two versions of Clang, we need to ensure that
On Fri, Oct 20, 2023 at 12:22 PM Ken Matsui wrote:
>
> This patch optimizes the compilation performance of std::is_invocable
> by dispatching to the new __is_invocable built-in trait.
>
> libstdc++-v3/ChangeLog:
>
> * include/std/type_traits (is_invocable): Use __is_invocable
> bui
On Mon, 23 Oct 2023, Ken Matsui wrote:
> On Mon, Oct 23, 2023 at 10:05 AM Patrick Palka wrote:
> On Fri, Oct 20, 2023 at 12:22 PM Ken Matsui wrote:
> >
> > This patch optimizes the compilation performance of std::is_invocable
> > by dispatching t
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
After the removal of NON_DEPENDENT_EXPR, cp_stabilize_reference which
used to just exit early for NON_DEPENDENT_EXPR is now more prone to
passing a weird templated tree to middle-end routines, which leads to
The second patch in this series is new and ensures that the candidates
list isn't mysteriously missing some candidates when noting other
candidates due to deletedness.
-- >8 --
This patch:
* changes splice_viable to move the non-viable candidates to the end
of the list instead of removing
During overload resolution, we sometimes outright ignore a function from
the overload set and leave no trace of it in the candidates list, for
example when we find a perfect non-template candidate we discard all
function templates, or when the callee is a template-id we discard all
non-template fun
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g.:
deleted16.C: In function 'int main()':
deleted16.C:10:4: error: use of deleted function 'void f(int)'
10 | f(0);
| ~^~~
deleted16.C:5:6: note:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
like the right approach?
-- >8 --
This PR is another instance of NON_DEPENDENT_EXPR having acted as an
"analysis barrier" for middle-end routines, and now that it's gone we
may end up passing weird templated trees (that have a gene
Tested on x86_64-pc-linux-gnu, pushed to trunk.
-- >8 --
We accept the non-dependent call f(e) here ever since the
NON_DEPENDENT_EXPR removal patch r14-4793-gdad311874ac3b3.
I haven't looked closely into why but I suspect wrapping 'e'
in a NON_DEPENDENT_EXPR was causing the argument conversion
to
On Tue, 24 Oct 2023, Jason Merrill wrote:
> On 10/24/23 13:03, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > like the right approach?
> >
> > -- >8 --
> >
> > This PR is another instance of NON_DEPEN
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
We also need to avoid folding 'outer_nelts_check' when in a template
context to prevent an ICE on the below testcase. This patch achieves
this by replacing the fold_build2 call with build2 (cp_fully_fold wil
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
Declaring get() inline seems necessary to avoid link failure:
/usr/bin/ld: /tmp/ccwdv6Co.o: in function `g3@pr105322.Decltype()':
decltype-1_b.C:(.text._ZW8pr105322W8Decltype2g3v[_ZW8pr105322W8Decltype2g3v]+0x18):
undefined referen
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Now that we don't have to worry about looking thruogh NON_DEPENDENT_EXPR,
we can easily extend the -Wparentheses warning in convert_for_assignment
to consider (non-dependent) templated assignment operator exp
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
OK for trunk?
-- >8 --
Since when in a template context we end up just discarding the result
of build_new_1, we don't have to bother with much of the code generation
it performs. This patch makes the function exit early, returning
On Thu, 26 Oct 2023, Jason Merrill wrote:
> On 10/26/23 14:01, Patrick Palka wrote:
> > Since when in a template context we end up just discarding the result
> > of build_new_1, we don't have to bother with much of the code generation
> > it performs. This patch mak
On Thu, 26 Oct 2023, Jason Merrill wrote:
> On 10/25/23 14:55, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > Now that we don't have to worry about looking thruo
On Thu, 26 Oct 2023, Patrick Palka wrote:
> On Thu, 26 Oct 2023, Jason Merrill wrote:
>
> > On 10/25/23 14:55, Patrick Palka wrote:
> > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > > OK for trunk?
> > >
> > > -- >8 --
N.B. we currently don't diagnose 'new A(1)' below ultimately because
when in a template context our valid ctor call checking only happens for
type_build_ctor_call types.
-- >8 --
gcc/testsuite/ChangeLog:
* g++.dg/template/new14.C: New test.
---
gcc/testsuite/g++.dg/template/new14.C | 20
With the previous two patches in place, we can now extend our
deletedness diagnostic to note the other considered candidates, e.g.:
deleted16.C: In function 'int main()':
deleted16.C:10:4: error: use of deleted function 'void f(int)'
10 | f(0);
| ~^~~
deleted16.C:5:6: note:
During overload resolution, we sometimes outright ignore a function in
the overload set and leave no trace of it in the candidates list, for
example when we find a perfect non-template candidate we discard all
function templates, or when the callee is a template-id we discard all
non-template funct
New in patch 1/3:
* consistently use "non-viable" instead of "unviable"
throughout
* make 'champ' and 'challenger' in 'tourney' be z_candidate**
to simplify moving 'champ' to the front of the list. drive-by
cleanups in tourney, including renaming 'champ_compared_to_predecessor'
On Fri, 20 Oct 2023, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk. Patrick, sorry I didn't apply
> this sooner.
>
> -- 8< --
>
> In r13-3766 I changed the logic at the end of tourney to avoid redundant
> comparisons, but the change also meant skipping any less-good match
On Fri, 27 Oct 2023, Patrick Palka wrote:
> On Fri, 20 Oct 2023, Jason Merrill wrote:
>
> > Tested x86_64-pc-linux-gnu, applying to trunk. Patrick, sorry I didn't
> > apply
> > this sooner.
> >
> > -- 8< --
> >
> > In r13-3766 I ch
On Fri, 27 Oct 2023, Patrick Palka wrote:
> On Fri, 27 Oct 2023, Patrick Palka wrote:
>
> > On Fri, 20 Oct 2023, Jason Merrill wrote:
> >
> > > Tested x86_64-pc-linux-gnu, applying to trunk. Patrick, sorry I didn't
> > > apply
> > > this soon
On Fri, 27 Oct 2023, Jason Merrill wrote:
> On 10/27/23 15:55, Patrick Palka wrote:
> > With the previous two patches in place, we can now extend our
> > deletedness diagnostic to note the other considered candidates, e.g.:
> >
> >deleted16.C: In function 'in
On Fri, 27 Oct 2023, Patrick Palka wrote:
> On Fri, 27 Oct 2023, Jason Merrill wrote:
>
> > On 10/27/23 15:55, Patrick Palka wrote:
> > > With the previous two patches in place, we can now extend our
> > > deletedness diagnostic to note the ot
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Does it look OK for release branches as well for sake of PR111703?
-- >8 --
potential_constant_expression was incorrectly treating most local
variables from a constexpr function as (potentially) constant because it
w
On Tue, 31 Oct 2023, Patrick Palka wrote:
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk? Does it look OK for release branches as well for sake of PR111703?
>
> -- >8 --
>
> potential_constant_expression was incorrectly treating most loc
On Tue, 3 May 2022, Jason Merrill wrote:
> On 5/2/22 14:50, Patrick Palka wrote:
> > Currently when checking the constraints of a class template, we do so in
> > the context of the template, not the specialized type. This is the best
> > we can do for a primary template
yn Sat, 28 Oct 2023, Feng Jisen wrote:
> This patch remove a redundant partial specialization in class _Nth_type.
> For the original metafunction _Nth_type code,
> # 0
> template struct _Nth_type<0, _Tp0,
> _Rest...>
> { using type = _Tp0; };
> # 1
> template
> struct _Nth_type
The leak in get_mapped_args is due to auto_vec not properly supporting
destructible elements, in that auto_vec's destructor doesn't call the
destructors of its elements.
Successfully bootstrapped and regtested on x86_64-pc-linux-gnu, OK to commit?
gcc/cp/ChangeLog:
* constraint.cc (get_m
It seems that in practice std::sentinel_for is always true, and so the
test_range container doesn't help us detect bugs in ranges code in which we
wrongly assume that a sentinel can be manipulated like an iterator. Make the
test_range container more strict by having end() unconditionally return a
On Tue, 21 Jan 2020, Jason Merrill wrote:
On 1/20/20 8:06 PM, Patrick Palka wrote:
The leak in get_mapped_args is due to auto_vec not properly supporting
destructible elements, in that auto_vec's destructor doesn't call the
destructors of its elements.
Hmm, perhaps vec should sta
On Wed, 29 Jan 2020, Jonathan Wakely wrote:
On 21/01/20 17:26 -0500, Patrick Palka wrote:
It seems that in practice std::sentinel_for is always true, and so
the
Doh, good catch.
test_range container doesn't help us detect bugs in ranges code in which we
wrongly assume that a sentine
On Wed, 29 Jan 2020, Patrick Palka wrote:
On Wed, 29 Jan 2020, Jonathan Wakely wrote:
On 21/01/20 17:26 -0500, Patrick Palka wrote:
It seems that in practice std::sentinel_for is always true, and so
the
Doh, good catch.
test_range container doesn't help us detect bugs in ranges co
Currently this script doesn't set the indentation style for the standard library
headers under libstdc++/ because they lack a file extension. But they do
have a modeline, so the file type is still set appropriately by Vim. So by
inspecting &filetype, we can also detect these standard library head
These changes are needed for some of the tests in the constrained algorithm
patch, because they use move_iterator with an uncopyable output_iterator. The
other changes described in the paper are already applied, it seems.
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (move_iterat
This patch implements [range.adaptors]. It also includes the changes from P3280
and P3278 and P3323, without which many standard examples won't work.
The implementation is mostly dictated by the spec and there was not much room
for implementation discretion. The most interesting part that was no
On Tue, 4 Feb 2020, Jonathan Wakely wrote:
> On 03/02/20 21:07 -0500, Patrick Palka wrote:
> > These changes are needed for some of the tests in the constrained algorithm
> > patch, because they use move_iterator with an uncopyable output_iterator.
> > The
> > other cha
os-adaptors
>
> On 2/4/20 3:07 AM, Patrick Palka wrote:
> > This patch implements the C++20 ranges overloads for the algorithms in
> > [algorithms]. Most of the algorithms were reimplemented, with each of their
> > implementations very closely following the exis
On Thu, 6 Feb 2020, Jonathan Wakely wrote:
> On 03/02/20 21:07 -0500, Patrick Palka wrote:
> > This patch implements [range.adaptors]. It also includes the changes from
> > P3280
> > and P3278 and P3323, without which many standard examples won't work.
> >
This patch adds ranges::basic_istream_view and ranges::istream_view. This seems
to be the last missing part of the ranges header.
libstdc++-v3/ChangeLog:
* include/std/ranges (ranges::__detail::__stream_extractable,
ranges::basic_istream_view, ranges::istream_view): Define.
On Thu, 6 Feb 2020, Jonathan Wakely wrote:
> On 03/02/20 21:07 -0500, Patrick Palka wrote:
> > +#ifndef _RANGES_ALGO_H
> > +#define _RANGES_ALGO_H 1
> > +
> > +#if __cplusplus > 201703L
> > +
> > +#include
> > +#include
> > +#include
>
On Fri, 7 Feb 2020, Jonathan Wakely wrote:
> On 06/02/20 18:53 -0500, Patrick Palka wrote:
> > On Thu, 6 Feb 2020, Jonathan Wakely wrote:
> > > > +#ifdef __cpp_lib_threeway_comparison
> > >
> > > This macro is mispelled, should be three_way with an undersc
On Fri, 7 Feb 2020, Jonathan Wakely wrote:
> On 06/02/20 19:52 -0500, Patrick Palka wrote:
> > This patch adds ranges::basic_istream_view and ranges::istream_view. This
> > seems
> > to be the last missing part of the ranges header.
> >
> > libstdc++-v3/Chan
Since basic_istream_view::iterator is neither a cpp17 iterator (because it's
move-only) nor does it define all four of the types {difference_type,
value_type, reference, iterator_category}, then by the rule in
[iterator.traits], its iterator_traits has no members.
More concretely this means that i
This patch fixes two issues with return type deduction in the presence of an
abbreviated function template.
The first issue (PR 69448) is that if a placeholder auto return type contains
any modifiers such as & or *, then the abbreviated-function-template
compensation in splice_late_return_type doe
On Mon, 10 Feb 2020, Jonathan Wakely wrote:
> On 07/02/20 13:59 -0500, Patrick Palka wrote:
> > Since basic_istream_view::iterator is neither a cpp17 iterator (because it's
> > move-only) nor does it define all four of the types {difference_type,
> > value_type, re
This patch improves the pretty printing of standard concept definitions in error
messages. In particular, standard concepts are now printed qualified whenever
appropriate, and the "concept" specifier is printed only when the
TFF_DECL_SPECIFIERS flag is specified.
In the below test, the first erro
On Mon, 10 Feb 2020, Jason Merrill wrote:
> On 2/10/20 2:20 PM, Patrick Palka wrote:
> > This patch fixes two issues with return type deduction in the presence of an
> > abbreviated function template.
> >
> > The first issue (PR 69448) is that if a placeholder au
libstdc++-v3/ChangeLog:
DR 3389 and DR 3390
* include/bits/stl_iterator.h (move_move_iterator): Use std::move when
constructing the move_iterator with __i.
(counted_iterator::counted_iterator): Use std::move when initializing
M_current with __i.
* te
On Tue, 11 Feb 2020, Patrick Palka wrote:
> libstdc++-v3/ChangeLog:
>
> DR 3389 and DR 3390
> * include/bits/stl_iterator.h (move_move_iterator): Use std::move when
> constructing the move_iterator with __i.
> (counted_iterator::counted_iterator):
This patch adds memoization for these four views so that their begin() has the
required constant time amortized complexity.
In the general case we use std::optional to cache the result. When the
underlying range is a random_access_range then we store the cache as an offset
from the beginning of t
Two equal atomic constraint expressions do not necessarily share the same tree,
so we can't assume that two ATOMIC_CONST_EXPRs are equal if and only if they
point to the same tree. The main consequence of this invalid assumption is that
the constraint subsumption checker may reject a valid partial
This roughly mirrors the existing split between and
. The ranges [specialized.algorithms] will use this new
header to avoid including all of of .
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add bits/ranges_algobase.h
* include/Makefile.in: Regenerate.
* bits/ranges_al
This implements all the ranges members defined in [specialized.algorithms]:
ranges::uninitialized_default_construct
ranges::uninitialized_value_construct
ranges::uninitialized_copy
ranges::uninitialized_copy_n
ranges::uninitialized_move
ranges::uninitialized_move_n
ranges::uninitiali
On Thu, 13 Feb 2020, Jonathan Wakely wrote:
> On 12/02/20 15:41 -0500, Patrick Palka wrote:
> > This implements all the ranges members defined in [specialized.algorithms]:
> >
> > ranges::uninitialized_default_construct
> > ranges::uninitialized_value_construct
>
On Fri, 14 Feb 2020, Jason Merrill wrote:
> On 2/12/20 5:15 PM, Patrick Palka wrote:
> > Two equal atomic constraint expressions do not necessarily share the same
> > tree,
> > so we can't assume that two ATOMIC_CONST_EXPRs are equal if and only if they
> > poin
These subroutines have only a single call site, so it might be best and simplest
to eliminate them before we convert the algos into function objects.
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (ranges::__find_end): Fold into ...
(ranges::find_end): ... here.
(ran
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h: Adjust whitespace and formatting.
* include/bits/ranges_algobase.h: Likewise.
* include/bits/ranges_uninitialized.h: Likewise.
---
libstdc++-v3/include/bits/ranges_algo.h | 631 ++
libstdc++-v3/inc
This is the standard way to inhibit ADL for these entities, which is required as
per [algorithms.requirements] p2 and [specialized.algorithms] p4. The
conversion was done mostly mechanically with a custom Vim macro.
[ To make it easier to review, the diffstat below was generated with the -w
f
On Sat, 15 Feb 2020, Jonathan Wakely wrote:
> On 14/02/20 10:35 -0500, Patrick Palka wrote:
> > These subroutines have only a single call site, so it might be best and
> > simplest
> > to eliminate them before we convert the algos into function objects.
> >
This avoids instantiating dead code when the true branch of the constexpr if is
taken.
[ diffstat generated with -w to ignore noisy whitespace changes ]
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__lexicographical_compare_fn::operator()):
Move code after an early exit
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 2/29/24 15:56, Patrick Palka wrote:
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> > OK for trunk?
> >
> > -- >8 --
> >
> > For local enums defined in a non-template function or a fu
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 2/29/24 14:17, Patrick Palka wrote:
> > On Wed, 28 Feb 2024, Jason Merrill wrote:
> > > I wonder about, rather than returning it directly, setting its level to 1
> > > for
> > > the substitution?
> >
>
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 10:00, Patrick Palka wrote:
> > On Fri, 1 Mar 2024, Jason Merrill wrote:
> >
> > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
> >
On Fri, 1 Mar 2024, Jason Merrill wrote:
> On 3/1/24 10:32, Jason Merrill wrote:
> > On 3/1/24 10:00, Patrick Palka wrote:
> > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > > Bootst
On Fri, 1 Mar 2024, Patrick Palka wrote:
> On Fri, 1 Mar 2024, Jason Merrill wrote:
>
> > On 3/1/24 10:00, Patrick Palka wrote:
> > > On Fri, 1 Mar 2024, Jason Merrill wrote:
> > >
> > > > On 2/29/24 15:56, Patrick Palka wrote:
> > > > >
1 - 100 of 2094 matches
Mail list logo
