On Thu, 22 Sep 2022, Nathan Sidwell wrote:
> On 9/22/22 14:25, Patrick Palka wrote:
>
> > index 80467c19254..722b64793ed 100644
> > --- a/gcc/cp/decl.cc
> > +++ b/gcc/cp/decl.cc
> > @@ -18235,9 +18235,11 @@ maybe_register_incomplete_var (tree var)
> > {
> > /* When the outermost open
When streaming in the artificial VAR_DECL synthesized for a class NTTP
argument, we end up crashing from complete_vars because the call to
maybe_register_incomplete_var from add_module_namespace_decl for this
VAR_DECL pushes an unexpected NULL_TREE type onto the incomplete_vars
vector.
This patch
With partial variable template specializations, it looks like we
stream the VAR_DECL (i.e. the DECL_TEMPLATE_RESULT of the corresponding
TEMPLATE_DECL) since process_partial_specialization adds it to the
specializations table, but end up never streaming the corresponding
TEMPLATE_DECL itself that
This adds some recently implemented C++20/23 library headers to the
xtreme-header tests as appropriate. Also, it looks like we can safely
re-add and remove the NO_ASSOCIATED_LAMBDA workaround.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
gcc/testsuite/ChangeLog:
*
The modules streaming code seems to rely on the invariant that a
TEMPLATE_DECL and its DECL_TEMPLATE_RESULT have the same TREE_TYPE.
But for a templated VAR_DECL with deduced non-dependent type, the two
TREE_TYPEs end up diverging: cp_finish_decl deduces the type of the
initializer ahead of time
On Tue, 20 Sep 2022, Nathan Sidwell wrote:
> On 9/19/22 09:52, Patrick Palka wrote:
> > It looks like some xtreme-header-* tests are failing after the libstdc++
> > change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
> > to stream PACK_EXPANSION_EXTRA_ARGS, which leads to false
It looks like some xtreme-header-* tests are failing after the libstdc++
change r13-2158-g02f6b405f0e9dc ultimately because we're neglecting
to stream PACK_EXPANSION_EXTRA_ARGS, which leads to false equivalences
of different partial instantiations of _TupleConstraints::__constructible.
Tested on
On Sat, 17 Sep 2022, Jason Merrill wrote:
> On 9/16/22 10:59, Patrick Palka wrote:
> > On Fri, 16 Sep 2022, Jason Merrill wrote:
> >
> > > On 9/15/22 11:58, Patrick Palka wrote:
> > > > Here we're crashing during constraint matching for the instantiated
> > > > hidden friends due to two issues
On Fri, 16 Sep 2022, Nathan Sidwell wrote:
> Thanks, this looks right. Sigh templates can mess up ones mental invariants!
> The test case should really be a foo_[ab].C kind, to test both sides of the
> streaming. Bonus points for using the template after importing. And you need
> the
On Fri, 16 Sep 2022, Patrick Palka wrote:
> On Fri, 16 Sep 2022, Jason Merrill wrote:
>
> > On 9/15/22 11:58, Patrick Palka wrote:
> > > Here we're crashing during constraint matching for the instantiated
> > > hidden friends due to two issues with dependent substitution into a
> > >
On Fri, 16 Sep 2022, Jason Merrill wrote:
> On 9/15/22 11:58, Patrick Palka wrote:
> > Here we're crashing during constraint matching for the instantiated
> > hidden friends due to two issues with dependent substitution into a
> > TEMPLATE_ID_EXPR naming a template from the current instantiation
A couple of xtreme-header-* modules tests began ICEing in C++23 mode
ever since r13-2650-g5d84a4418aa962 introduced into the
dependently scoped friend declaration
friend /* typename */ _OuterIter::value_type;
ultimately because the streaming code assumes a TYPE_P friend must
be a class type,
This patch permits accessing 'mutable' members of local objects during
constexpr evaluation (which other compilers seem to accept in C++14
mode, while we reject), while continuing to reject it for global objects
(as in the last line of cpp0x/constexpr-mutable1.C, which other
compilers also
Here we're crashing during constraint matching for the instantiated
hidden friends due to two issues with dependent substitution into a
TEMPLATE_ID_EXPR naming a template from the current instantiation
(as performed from maybe_substitute_reqs_for for C<3> with T=T):
* tsubst_copy substitutes
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__adjacent_find_fn, adjacent_find):
Move to ...
* include/bits/ranges_util.h: ... here.
* include/std/ranges (chunk_by_view): Define.
Tested on x86_64-pc-linux-gnu, committed to trunk as obvious.
gcc/cp/ChangeLog:
* cp-tree.h (mark_used): Remove single-parameter overload. Add
default argument to the two-parameter overload.
* decl2.cc (mark_used): Likewise.
---
gcc/cp/cp-tree.h | 4 ++--
On Tue, 13 Sep 2022, Jason Merrill wrote:
> On 9/13/22 07:45, Patrick Palka wrote:
> > It looks like we aren't respecting SFINAE for:
> >
> >* an invalid/non-constant conditional explicit-specifier
> >* a non-constant conditional noexcept-specifier
> >* a non-constant argument to
It looks like we aren't respecting SFINAE for:
* an invalid/non-constant conditional explicit-specifier
* a non-constant conditional noexcept-specifier
* a non-constant argument to __integer_pack
This patch fixes these issues in the usual way, by passing complain
and propagating
I noticed compiling e.g. std/ranges/adaptors/join.cc with
-D_GLIBCXX_DEBUG -Wsystem-headers -Wall gives the warning:
gcc/libstdc++-v3/include/debug/safe_iterator.h:477:9: warning: suggest
parentheses around ‘&&’ within ‘||’ [-Wparentheses]
Tested on x86_64-pc-linux-gnu, does this look OK for
This also implements the LWG 3711 and 3712 changes to slide_view.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__slide_caches_nothing): Define.
(__detail::__slide_caches_last): Define.
(__detail::__slide_caches_first): Define.
(slide_view): Define.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk only?
libstdc++-v3/ChangeLog:
* include/std/ranges (join_view::_Iterator::_M_satisfy):
Adjust resetting _M_inner as per LWG 3569.
(join_view::_Iterator::_M_inner): Wrap in std::optional
as per LWG 3569.
This also implements the LWG 3707, 3710 and 3712 changes to chunk_view.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__div_ceil): Define.
(chunk_view): Define.
(chunk_view::_OuterIter): Define.
(chunk_view::_OuterIter::value_type): Define.
Although PR106320 only affected the 10 and 11 branches, and the testcase
from there was already correctly accepted on trunk and the 12 branch, we
should also add the testcase to 12/trunk for inter-branch consistency.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/12?
PR
PR libstdc++/106798
libstdc++-v3/ChangeLog:
* include/std/ranges (adjacent_view::_Iterator::_Iterator): Fix
typo.
* testsuite/std/ranges/adaptors/adjacent/1.cc (test04): New test.
---
libstdc++-v3/include/std/ranges | 2 +-
Tested on x86_64-pc-linux-gnu, does this series look OK for trunk?
PR libstdc++/106803
libstdc++-v3/ChangeLog:
* include/std/ranges (views::_ZipTransform::operator()): Fix
return type in the empty case.
(views::_AdjacentTransform::operator()): Likewise.
---
make_unsigned_t can't give us the unsigned version of an integer-class
difference type, so use __make_unsigned_like_t / __to_unsigned_like
instead.
PR libstdc++/106766
libstdc++-v3/ChangeLog:
* include/std/ranges (zip_view::_Iterator::operator-): Use
__to_unsigned_like
Each of the following functions
instantiate_non_dependent_expr
get_target_expr
require_complete_type
abstract_virtuals_error
cxx_constant_value
is (presumably for historical reasons) just a non-SFINAE-enabled wrapper
for the corresponding SFINAE-enabled version that's suffixed by
This was incidentally fixed by r13-806-g221acd67ca50f8.
PR c++/99209
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-uneval17.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/lambda-uneval17.C | 17 +
1 file changed, 17 insertions(+)
create mode 100644
On Wed, 7 Sep 2022, Jason Merrill wrote:
> On 9/7/22 15:41, Patrick Palka wrote:
> > Here the use of the constexpr member/variable specialization 'value'
> > from within an unevaluated context causes us to overeagerly instantiate
> > it, via maybe_instantiate_decl called from mark_used, despite
Here the use of the constexpr member/variable specialization 'value'
from within an unevaluated context causes us to overeagerly instantiate
it, via maybe_instantiate_decl called from mark_used, despite only its
declaration not its definition being needed.
We used to have the same issue for
Instead of defining these in terms of a helper class template
and the relatively expensive __remove_cv_t, just declare four
explicit specializations of the main template, one for each choice
of cv-quals.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
The is_void change alone reduces
Instead of defining is_reference in terms of is_lvalue_reference
and is_rvalue_reference, just define it directly.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
This reduces memory usage of join.cc by 1%.
libstdc++-v3/ChangeLog:
* include/std/type_traits (is_reference):
Now that these internal type traits are again class templates, it's
better to derive from the trait's ::type (which is either false_type or
true_type) instead of from the trait itself, for sake of a shallower
inheritance chain. We usually do this but not always; this patch makes
us consistently
On Fri, 2 Sep 2022, Patrick Palka wrote:
> r13-2230-g390f94eee1ae69 redefined the internal logical operator traits
> __and_, __or_ and __not as alias templates that directly resolve to
> true_type or false_type. But it turns out using an alias template here
> causes the traits to be less lazy
r13-2230-g390f94eee1ae69 redefined the internal logical operator traits
__and_, __or_ and __not as alias templates that directly resolve to
true_type or false_type. But it turns out using an alias template here
causes the traits to be less lazy than before because we now compute
the logical
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, clean the function up a
bit.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__advance_fn::operator()): Add
parentheses in assert condition to avoid -Wparentheses warning.
* include/std/ranges: (take_view::take_view): Uglify 'base'.
On Wed, 31 Aug 2022, Jonathan Wakely wrote:
> On Tue, 30 Aug 2022 at 18:14, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
>
> > +constexpr
> > +_Iterator(__as_sentinel, iterator_t<_Base> __first, iterator_t<_Base>
> >
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__unarize): Define.
(adjacent_view::_Iterator): Befriend adjacent_transform_view.
(adjacent_transform_view): Define.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* testsuite/20_util/logical_traits/requirements/short_circuit.cc: New
test.
---
.../requirements/short_circuit.cc | 32 +++
1 file changed, 32 insertions(+)
create mode
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (adjacent_view): Define.
(enable_borrowed_range): Define.
(__detail::__repeated_tuple): Define.
(adjacent_view::_Iterator): Define.
On Wed, 24 Aug 2022, Patrick Palka wrote:
> The internal type-level logical operations __and_ and __or_ are
> currently quite slow to compile for a couple of reasons:
>
> 1. They are drop-in replacements for std::con/disjunction, which
> are rigidly specified to form a type that derives
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* testsuite/20_util/logical_traits/requirements/base_classes.cc: New
test.
---
.../requirements/base_classes.cc | 37 +++
1 file changed, 37 insertions(+)
create mode
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (zip_view::_Iterator): Befriend
zip_transform_view.
(__detail::__range_iter_cat): Define.
(zip_transform_view): Define.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges (zip_view::_Iterator::operator<): Remove.
(zip_view::_Iterator::operator>): Remove.
(zip_view::_Iterator::operator<=): Remove.
libstdc++-v3/ChangeLog:
* include/std/ranges (lazy_split_view::_OuterIter::_M_current):
Remove redundant comment.
(lazy_split_view::_M_current): Likewise.
(common_view::common_view): Remove commented out view-converting
constructor as per LWG3405.
The internal type-level logical operations __and_ and __or_ are
currently quite slow to compile for a couple of reasons:
1. They are drop-in replacements for std::con/disjunction, which
are rigidly specified to form a type that derives from the first
type argument that caused the
On Wed, 24 Aug 2022, Patrick Palka wrote:
> r13-2159-g72886fcc626953 introduced some testsuite regressions in C++23
> mode:
>
> FAIL: 20_util/pair/requirements/explicit_instantiation/1.cc (test for
> excess errors)
> FAIL: 20_util/tuple/53648.cc (test for excess errors)
> FAIL:
r13-2159-g72886fcc626953 introduced some testsuite regressions in C++23
mode:
FAIL: 20_util/pair/requirements/explicit_instantiation/1.cc (test for excess
errors)
FAIL: 20_util/tuple/53648.cc (test for excess errors)
FAIL: 20_util/tuple/cons/noexcept_specs.cc (test for excess errors)
On Tue, 23 Aug 2022, Jonathan Wakely wrote:
> On Tue, 23 Aug 2022 at 02:36, Patrick Palka via Libstdc++
> wrote:
> > --- a/libstdc++-v3/include/bits/stl_pair.h
> > +++ b/libstdc++-v3/include/bits/stl_pair.h
> > @@ -212,6 +212,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > swap(second,
On Tue, 23 Aug 2022, Jonathan Wakely wrote:
> On Tue, 23 Aug 2022 at 02:35, Patrick Palka via Libstdc++
> wrote:
> >
> > P2321R2 adds new conditionally explicit constructors to std::tuple which
> > we'll concisely implement in a subsequent patch using explicit(bool), like
> > in our C++20
This implements the non- changes from P2321R2, which primarily
consist of new converting constructors, assignment operator and swap
overloads for std::pair and std::tuple.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/stl_bvector.h
Tested on 86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__min_fn, min): Move to ...
* include/bits/ranges_util.h: ... here in order to avoid
including all of ranges_algo.h from .
* include/std/ranges
P2321R2 adds new conditionally explicit constructors to std::tuple which
we'll concisely implement in a subsequent patch using explicit(bool), like
in our C++20 std::pair implementation. But before we can do that, this
patch first adds members to _TupleConstraints that test for constructibility
On Fri, Jul 22, 2022 at 11:52 AM Patrick Palka wrote:
>
> The 11 and 10 partial backports of P2325R3, r11-9555-g92d6121eec and
> r10-10808-g22b86cdc4d7fdd, unnecessarily preserved some changes from the
> paper that made certain views no longer default constructible, changes
> which aren't
The 11 and 10 partial backports of P2325R3, r11-9555-g92d6121eec and
r10-10808-g22b86cdc4d7fdd, unnecessarily preserved some changes from the
paper that made certain views no longer default constructible, changes
which aren't required to reap the overall benefits of the paper and
which
On Thu, 21 Jul 2022, Patrick Palka wrote:
> During CTAD, we currently perform the first phase of overload resolution
> from [over.match.list] only if the class template has a list constructor.
> But according to [over.match.class.deduct]/4 it should be enough to just
> have a guide that looks
During CTAD, we currently perform the first phase of overload resolution
from [over.match.list] only if the class template has a list constructor.
But according to [over.match.class.deduct]/4 it should be enough to just
have a guide that looks like a list constructor (which is a more general
On Mon, 18 Jul 2022, Jason Merrill wrote:
> On 7/18/22 12:59, Patrick Palka wrote:
> > In case of l/rvalue or cv-qual mismatch during reference binding, we try
> > to give more helpful diagnostics by attempting a bad conversion that
> > ignores the mismatch. But in doing so, we may end up
In case of l/rvalue or cv-qual mismatch during reference binding, we try
to give more helpful diagnostics by attempting a bad conversion that
ignores the mismatch. But in doing so, we may end up instantiating an
ill-formed conversion function, something that would otherwise be
avoided if we
Here we were crashing when substituting a non-dependent call to a
consteval operator, whose CALL_EXPR_OPERATOR_SYNTAX flag we try to
propagate to the result, but the result isn't a CALL_EXPR since the
called function is consteval. This patch fixes this by checking the
result of extract_call_expr
Here we incorrectly deem the calls to func1, func2 and tmpl2 as
ambiguous ahead of time ultimately because we mishandle dependence
of a constrained member function from the current instantiation.
In type_dependent_expression_p, we consider the dependence of a
TEMPLATE_DECL's constraints (via
On Thu, 7 Jul 2022, Patrick Palka wrote:
> On Thu, 7 Jul 2022, Jason Merrill wrote:
>
> > On 7/6/22 15:26, Patrick Palka wrote:
> > > On Tue, 5 Jul 2022, Jason Merrill wrote:
> > >
> > > > On 7/5/22 10:06, Patrick Palka wrote:
> > > > > On Fri, 1 Jul 2022, Jason Merrill wrote:
> > > > >
> > >
On Thu, 7 Jul 2022, Jason Merrill wrote:
> On 7/6/22 15:26, Patrick Palka wrote:
> > On Tue, 5 Jul 2022, Jason Merrill wrote:
> >
> > > On 7/5/22 10:06, Patrick Palka wrote:
> > > > On Fri, 1 Jul 2022, Jason Merrill wrote:
> > > >
> > > > > On 6/29/22 13:42, Patrick Palka wrote:
> > > > > > In
On Tue, 5 Jul 2022, Jason Merrill wrote:
> On 7/5/22 10:06, Patrick Palka wrote:
> > On Fri, 1 Jul 2022, Jason Merrill wrote:
> >
> > > On 6/29/22 13:42, Patrick Palka wrote:
> > > > In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic
> > > > DECL_TI_ARGS corresponds to an
On Fri, 1 Jul 2022, Jason Merrill wrote:
> On 6/29/22 13:42, Patrick Palka wrote:
> > In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic
> > DECL_TI_ARGS corresponds to an identity mapping of the given arguments,
> > and hence its safe to always elide such substitution. But
On Wed, Jun 1, 2022 at 3:21 PM Jason Merrill via Gcc-patches
wrote:
>
> This testcase demonstrates that the issue in PR105623 is not limited to
> templates, so we should do the marking in a less template-specific place.
>
> Tested x86_64-pc-linux-gnu, applying to trunk.
>
> PR c++/105779
In r13-1045-gcb7fd1ea85feea I assumed that substitution into generic
DECL_TI_ARGS corresponds to an identity mapping of the given arguments,
and hence its safe to always elide such substitution. But this PR
demonstrates that such a substitution isn't always the identity mapping,
in particular
Changing the type of N from int to unsigned in decltype82.C from
r12-8472-g47ea22015c90df reveals another spot where we perform
constexpr evaluation in an unevaluated context for sake of diagnostics,
this time from the call to shorten_compare in cp_build_binary_op,
which calls fold_for_warn.
We
The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated. In particular, it can happen for a non-dependent
specialization of a nested
On Fri, 10 Jun 2022, Patrick Palka wrote:
> On Thu, 9 Jun 2022, Patrick Palka wrote:
>
> > On Thu, 9 Jun 2022, Jason Merrill wrote:
> >
> > > On 6/8/22 14:21, Patrick Palka wrote:
> > > > When substituting a class template specialization, tsubst_aggr_type
> > > > substitutes the TYPE_CONTEXT
The reason compiling the testcase in this PR is so slow is ultimately
due to our poor hashing of TYPENAME_TYPE causing a huge amount of hash
table collisions in the spec_hasher and typename_hasher tables.
In spec_hasher, we don't hash the components of a TYPENAME_TYPE at all,
presumably because
On Thu, 9 Jun 2022, Patrick Palka wrote:
> On Thu, 9 Jun 2022, Jason Merrill wrote:
>
> > On 6/8/22 14:21, Patrick Palka wrote:
> > > When substituting a class template specialization, tsubst_aggr_type
> > > substitutes the TYPE_CONTEXT before passing it to lookup_template_class.
> > > This
On Thu, 9 Jun 2022, Jason Merrill wrote:
> On 6/9/22 09:00, Patrick Palka wrote:
> > This performs one of the optimizations added by the previous
> > patch to lookup_template_class, to instantiate_template as well.
> > (For the libstdc++ ranges tests this optimization appears to be
> > effective
On Thu, 9 Jun 2022, Jason Merrill wrote:
> On 6/8/22 14:21, Patrick Palka wrote:
> > When substituting a class template specialization, tsubst_aggr_type
> > substitutes the TYPE_CONTEXT before passing it to lookup_template_class.
> > This appears to be unnecessary, however, because the the
This performs one of the optimizations added by the previous
patch to lookup_template_class, to instantiate_template as well.
(For the libstdc++ ranges tests this optimization appears to be
effective around 30% of the time, i.e. 30% of the time context of 'tmpl'
is non-dependent while the context
When substituting a class template specialization, tsubst_aggr_type
substitutes the TYPE_CONTEXT before passing it to lookup_template_class.
This appears to be unnecessary, however, because the the initial value
of lookup_template_class's context parameter is unused outside of the
IDENTIFIER_NODE
On Tue, 7 Jun 2022, Jason Merrill wrote:
> On 6/7/22 09:24, Patrick Palka wrote:
> > On Mon, 6 Jun 2022, Jason Merrill wrote:
> >
> > > On 6/6/22 14:27, Patrick Palka wrote:
> > > > On Thu, 7 Oct 2021, Jason Merrill wrote:
> > > >
> > > > > On 10/7/21 11:17, Patrick Palka wrote:
> > > > > > On
On Wed, 23 Mar 2022, Jason Merrill wrote:
> On 3/22/22 14:31, Patrick Palka wrote:
> > On Tue, 22 Mar 2022, Patrick Palka wrote:
> >
> > > Here we're neglecting to clear cp_unevaluated_operand when substituting
> > > into the arguments of the alias template-id skip<(T(), 0), T> with T=A,
> > >
gcc/cp/ChangeLog:
* cp-tree.h (mark_used): Remove single-parameter overload. Add
default argument to the two-parameter overload.
* decl2.cc (mark_used): Likewise.
---
gcc/cp/cp-tree.h | 3 +--
gcc/cp/decl2.cc | 8 +---
2 files changed, 2 insertions(+), 9
On Mon, 6 Jun 2022, Jason Merrill wrote:
> On 6/6/22 14:27, Patrick Palka wrote:
> > On Thu, 7 Oct 2021, Jason Merrill wrote:
> >
> > > On 10/7/21 11:17, Patrick Palka wrote:
> > > > On Wed, 6 Oct 2021, Jason Merrill wrote:
> > > >
> > > > > On 10/6/21 15:52, Patrick Palka wrote:
> > > > > > On
On Thu, 7 Oct 2021, Jason Merrill wrote:
> On 10/7/21 11:17, Patrick Palka wrote:
> > On Wed, 6 Oct 2021, Jason Merrill wrote:
> >
> > > On 10/6/21 15:52, Patrick Palka wrote:
> > > > On Wed, 6 Oct 2021, Patrick Palka wrote:
> > > >
> > > > > On Tue, 5 Oct 2021, Jason Merrill wrote:
> > > > >
On Thu, 2 Jun 2022, Patrick Palka wrote:
> On Thu, 2 Jun 2022, Jason Merrill wrote:
>
> > On 6/1/22 14:20, Patrick Palka wrote:
> > > r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent
> > > decltype operands by relaxing instantiate_non_dependent_expr to check
> > >
On Fri, 3 Jun 2022, Marek Polacek wrote:
> On Fri, Jun 03, 2022 at 11:16:26AM -0400, Jason Merrill via Gcc-patches wrote:
> > On 6/3/22 11:04, Patrick Palka wrote:
> > > > > @@ -4319,15 +4319,32 @@ maybe_dummy_object (tree type, tree* binfop)
> > > > > if (binfop)
> > > > >*binfop =
On Fri, 3 Jun 2022, Jason Merrill wrote:
> On 6/3/22 10:46, Patrick Palka wrote:
> > On Thu, 2 Jun 2022, Jason Merrill wrote:
> >
> > > On 6/2/22 15:57, Patrick Palka wrote:
> > > > On Thu, 2 Jun 2022, Jason Merrill wrote:
> > > >
> > > > > On 5/27/22 09:57, Patrick Palka wrote:
> > > > > > On
On Thu, 2 Jun 2022, Jason Merrill wrote:
> On 6/2/22 15:57, Patrick Palka wrote:
> > On Thu, 2 Jun 2022, Jason Merrill wrote:
> >
> > > On 5/27/22 09:57, Patrick Palka wrote:
> > > > On Thu, 26 May 2022, Patrick Palka wrote:
> > > >
> > > > > On Thu, 26 May 2022, Jason Merrill wrote:
> > > > >
On Thu, 2 Jun 2022, Jason Merrill wrote:
> On 6/1/22 14:20, Patrick Palka wrote:
> > r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent
> > decltype operands by relaxing instantiate_non_dependent_expr to check
> > instantiation_dependent_uneval_expression_p. But as the
On Thu, 2 Jun 2022, Jason Merrill wrote:
> On 5/27/22 09:57, Patrick Palka wrote:
> > On Thu, 26 May 2022, Patrick Palka wrote:
> >
> > > On Thu, 26 May 2022, Jason Merrill wrote:
> > >
> > > > On 5/26/22 14:57, Patrick Palka wrote:
> > > > > On Thu, 26 May 2022, Patrick Palka wrote:
> > > > >
On Fri, 27 May 2022, Patrick Palka wrote:
> On Thu, 26 May 2022, Patrick Palka wrote:
>
> > On Thu, 26 May 2022, Jason Merrill wrote:
> >
> > > On 5/26/22 14:57, Patrick Palka wrote:
> > > > On Thu, 26 May 2022, Patrick Palka wrote:
> > > >
> > > > > Here we expect the calls to
On Tue, 31 May 2022, Jason Merrill wrote:
> On 5/31/22 08:56, Patrick Palka wrote:
> > On Sun, 29 May 2022, Jason Merrill wrote:
> >
> > > On 5/29/22 22:10, Jason Merrill wrote:
> > > > On 5/27/22 14:05, Patrick Palka wrote:
> > > > > This makes us avoid substituting into the
On Wed, 1 Jun 2022, Marek Polacek via Gcc-patches wrote:
> Here we ICE because value_dependent_expression_p gets a NEW_EXPR
> whose operand is a type, and we go to the default case which just
> calls v_d_e_p on each operand of the NEW_EXPR. Since one of them
> is a type, we crash on the new
r12-7564-gec0f53a3a542e7 made us instantiate non-constant non-dependent
decltype operands by relaxing instantiate_non_dependent_expr to check
instantiation_dependent_uneval_expression_p. But as the testcase below
demonstrates, this predicate is too permissive here because it allows
On Wed, 1 Jun 2022, Patrick Palka wrote:
> As explained in r11-4959-gde6f64f9556ae3, the atom cache assumes two
> equivalent expressions (according to cp_tree_equal) must use the same
> template parameters (according to find_template_parameters). This
> assumption turned out to not hold for
As explained in r11-4959-gde6f64f9556ae3, the atom cache assumes two
equivalent expressions (according to cp_tree_equal) must use the same
template parameters (according to find_template_parameters). This
assumption turned out to not hold for TARGET_EXPR, which was addressed
by that commit.
But
On Tue, 31 May 2022, Patrick Palka wrote:
> r12-5487-g9bf69a8558638c replaced uses of timevar_cond_push/pop with
> auto_cond_timevar and removed now unnecessary wrapper functions. This
> patch does the same for timevar_push/pop and auto_timevar.
>
> Bootstrapped and regtested on
r12-5487-g9bf69a8558638c replaced uses of timevar_cond_push/pop with
auto_cond_timevar and removed now unnecessary wrapper functions. This
patch does the same for timevar_push/pop and auto_timevar.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
This replaces the two differently named versions of the same function
with a single function using a default function argument.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
gcc/cp/ChangeLog:
* cp-tree.h (cp_build_qualified_type_real): Rename to ...
On Wed, 18 May 2022, Jason Merrill wrote:
> On 5/17/22 12:34, Patrick Palka wrote:
> > On Sat, May 7, 2022 at 5:18 PM Jason Merrill wrote:
> > >
> > > On 5/6/22 16:46, Patrick Palka wrote:
> > > > On Fri, 6 May 2022, Jason Merrill wrote:
> > > >
> > > > > On 5/6/22 16:10, Patrick Palka wrote:
Here the out-of-line definition of Z::z causes duplicate_decls to
change z's type to use the implicit instantiation Z rather than the
corresponding primary template type (which is also the type of the
injected class name), and the former, being a dependent specialization,
lacks a TYPE_BINFO
On Sun, 29 May 2022, Jason Merrill wrote:
> On 5/29/22 22:10, Jason Merrill wrote:
> > On 5/27/22 14:05, Patrick Palka wrote:
> > > This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of
> > > each template parameter except as necessary for (friend) declaration
> > > matching, like
401 - 500 of 1377 matches
Mail list logo
