On Wed, 29 Mar 2023, Jason Merrill wrote:
> On 3/28/23 13:37, Patrick Palka wrote:
> > Now that we resolve non-dependent variable template-ids ahead of time,
> > cp_finish_decl needs to handle a new invalid situation: we can end up
> > trying to instantiate a variable template with deduced return
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 hash table).
Since this appears to be possible only during constrained auto deduction
for a
On Wed, 29 Mar 2023, Jason Merrill wrote:
> On 3/17/23 11:26, Patrick Palka wrote:
> > Here we're crashing during satisfaction for the NTTP 'C auto' from
> > do_auto_deduction ultimately because convert_template_argument / unify
> > don't pass all outer template arguments to do_auto_deduction,
On Fri, 31 Mar 2023, Jason Merrill wrote:
> On 3/31/23 11:55, Patrick Palka wrote:
> > On Fri, 31 Mar 2023, Patrick Palka wrote:
> >
> > > On Thu, 30 Mar 2023, Jason Merrill wrote:
> > >
> > > > On 3/30/23 14:53, Patrick Palka wrote:
> > > > > On Wed, 29 Mar 2023, Jason Merrill wrote:
> > > > >
On Fri, 31 Mar 2023, Patrick Palka wrote:
> On Thu, 30 Mar 2023, Jason Merrill wrote:
>
> > On 3/30/23 14:53, Patrick Palka wrote:
> > > On Wed, 29 Mar 2023, Jason Merrill wrote:
> > >
> > > > On 3/27/23 09:30, Patrick Palka wrote:
> > > > > On Thu, 23 Mar 2023, Patrick Palka wrote:
> > > > >
On Thu, 30 Mar 2023, Jason Merrill wrote:
> On 3/30/23 14:53, Patrick Palka wrote:
> > On Wed, 29 Mar 2023, Jason Merrill wrote:
> >
> > > On 3/27/23 09:30, Patrick Palka wrote:
> > > > On Thu, 23 Mar 2023, Patrick Palka wrote:
> > > >
> > > > > r13-995-g733a792a2b2e16 worked around the problem
On Wed, 29 Mar 2023, Jason Merrill wrote:
> On 3/27/23 09:30, Patrick Palka wrote:
> > On Thu, 23 Mar 2023, Patrick Palka wrote:
> >
> > > r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL
> > > template arguments not always getting marked as odr-used by redundantly
> > >
Now that we resolve non-dependent variable template-ids ahead of time,
cp_finish_decl needs to handle a new invalid situation: we can end up
trying to instantiate a variable template with deduced return type
before we fully parsed (and attached) its initializer.
Bootstrapped and regtested on
On Fri, Mar 17, 2023 at 11:26 AM Patrick Palka wrote:
>
> Here we're crashing during satisfaction for the NTTP 'C auto' from
> do_auto_deduction ultimately because convert_template_argument / unify
> don't pass all outer template arguments to do_auto_deduction, and during
> satisfaction we need
On Thu, 23 Mar 2023, Patrick Palka wrote:
> r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL
> template arguments not always getting marked as odr-used by redundantly
> calling mark_used on the substituted ADDR_EXPR callee of a CALL_EXPR.
> This is just a narrow workaround
On Thu, Mar 23, 2023 at 5:18 PM Patrick Palka wrote:
>
> r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL
> template arguments not always getting marked as odr-used by redundantly
> calling mark_used on the substituted ADDR_EXPR callee of a CALL_EXPR.
> This is just a narrow
Here we're issuing a duplicate diagnostic for the use of the deleted
foo, first from the CALL_EXPR case of tsubst_copy_and_build (which
doesn't exit early upon failure), and again from from build_over_call
when rebuilding the substituted CALL_EXPR.
We can fix this by exiting early upon failure of
r13-995-g733a792a2b2e16 worked around the problem of FUNCTION_DECL
template arguments not always getting marked as odr-used by redundantly
calling mark_used on the substituted ADDR_EXPR callee of a CALL_EXPR.
This is just a narrow workaround however, since using a FUNCTION_DECL as
a template
Here when resolving the implicit object for '' within the
local class Foo, we expect to obtain a dummy object of type Foo& since
there's no 'this' available in this context. And yet at this point
current_class_ref still corresponds to the outer class Context (and is
const), which confuses
On Mon, Mar 20, 2023 at 5:56 AM Ken Matsui wrote:
>
> > Does it actually make compilation faster though?
> >
> > Has it been measured?
>
> In my understanding, what I have implemented so far is so simple that
> it does not affect the speed. These traits are what Partick kindly
> recommended to
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 end up pulling out its constant value, we
> go back at the
On Fri, 17 Mar 2023, Patrick Palka wrote:
> Here we're crashing during satisfaction for the NTTP 'C auto' from
> do_auto_deduction ultimately because convert_template_argument / unify
> don't pass all outer template arguments to do_auto_deduction, and during
> satisfaction we need to know all
Here we're crashing during satisfaction for the NTTP 'C auto' from
do_auto_deduction ultimately because convert_template_argument / unify
don't pass all outer template arguments to do_auto_deduction, and during
satisfaction we need to know all arguments. While these callers do
pass some outer
When satisfaction_cache::get detects constraint recursion, it asserts
that entry->result is empty. This makes sense when we're initially
detecting/diagnosing recursion from the inner recursive call, but
aftewards from the outer recursive call the recursion error is treated
like any other SFINAE
On Thu, 16 Mar 2023, Jason Merrill wrote:
> On 3/16/23 10:09, Patrick Palka wrote:
> > On Wed, 15 Mar 2023, Patrick Palka wrote:
> >
> > > On Thu, 9 Mar 2023, Jason Merrill wrote:
> > >
> > > > On 3/9/23 14:32, Patrick Palka wrote:
> > > > > On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches
On Wed, 15 Mar 2023, Patrick Palka wrote:
> On Thu, 9 Mar 2023, Jason Merrill wrote:
>
> > On 3/9/23 14:32, Patrick Palka wrote:
> > > On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote:
> > >
> > > > When processing a noexcept, constructors aren't elided: build_over_call
> > > > has
> > >
On Thu, 9 Mar 2023, Jason Merrill wrote:
> On 3/9/23 14:32, Patrick Palka wrote:
> > On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote:
> >
> > > When processing a noexcept, constructors aren't elided: build_over_call
> > > has
> > >/* It's unsafe to elide the constructor when handling
Tested on x86_64-pc-linux-gnu, pushed to trunk as obvious.
-- >8 --
PR libstdc++/109111
libstdc++-v3/ChangeLog:
* include/std/ranges (repeat_view): Remove redundant parentheses
in requires-clause.
(repeat_view::_Iterator): Correct the requires-clause.
---
Here when instantiating a constrained template friend naming an already
declared class template, we erroneously pass the existing template's
constraints instead of the friend declaration's constraints to
redeclare_class_template, which causes the constraint comparison check
therein to always be
When redeclaring a member of a constrained class template, we need to
repeat the class's constraints, but it turns out we don't verify
anywhere that the repeated constraints match the class's constraints.
A safe place to do so seems to be in push_template_decl, nearby a
similar consistency check
On Mon, 6 Mar 2023, Marek Polacek via Gcc-patches wrote:
> When processing a noexcept, constructors aren't elided: build_over_call
> has
>/* It's unsafe to elide the constructor when handling
> a noexcept-expression, it may evaluate to the wrong
> value (c++/53025).
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps
backports?
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (move_iterator::_S_iter_concept):
Define.
(__cpp_lib_move_iterator_concept): Define for C++20.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_util.h (view_interface::empty): Add
preferred overloads that use ranges::size when the range is
sized as per LWG 3715.
*
The LWG 3820 testcase revealed a bug in _M_advance, which this patch
also fixes.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/std/ranges
(cartesian_product_view::_Iterator::_Iterator): Remove
constraint on default
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and perhaps 12?
PR libstdc++/108362
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::__can_single_view): New concept.
(_Single::operator()): Constrain it. Move [[nodiscard]] to the
end of the
On Tue, 7 Mar 2023, Patrick Palka wrote:
> ranges::begin() isn't guaranteed to be equality-preserving for
> non-forward ranges, so in cartesian_product_view::end we need to be
> careful about calling begin() on the first range (which could be
> non-forward) in the (non-degenerate) case where
ranges::begin() isn't guaranteed to be equality-preserving for
non-forward ranges, so in cartesian_product_view::end we need to be
careful about calling begin() on the first range (which could be
non-forward) in the (non-degenerate) case where __empty_tail is false.
Since we're already using a
In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
extract_local_specs walk the given pattern twice, ignoring unevaluated
operands the first time around so that we prefer to process a local
specialization in an evaluated context if it appears in one (we process
a local
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 12:20, Patrick Palka wrote:
> > On Wed, 1 Mar 2023, Jason Merrill wrote:
> >
> > > On 3/1/23 10:32, Patrick Palka wrote:
> > > > On Mon, 27 Feb 2023, Jason Merrill wrote:
> > > >
> > > > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > > >
On Wed, 1 Mar 2023, Jason Merrill wrote:
> On 3/1/23 10:32, Patrick Palka wrote:
> > On Mon, 27 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/22/23 14:45, Patrick Palka wrote:
> > > > Here we're mishandling the unevaluated array new-expressions due to a
> > > > supposed non-constant array size
On Mon, 27 Feb 2023, Jason Merrill wrote:
> On 2/22/23 14:45, Patrick Palka wrote:
> > Here we're mishandling the unevaluated array new-expressions due to a
> > supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
> > made us no longer perform constant evaluation of
On Thu, 16 Feb 2023, Patrick Palka wrote:
> This fixes some header-defined functions that are undesirably declared
> static and weren't caught by the "^static inline" pattern used in the
> previous patch.
>
> gcc/ChangeLog:
>
> * hash-table.h (gt_pch_nx): Remove static.
> *
Here we're incorrectly treating the non-dependent variable template-id
tag as dependent ever since r226642 gave variable TEMPLATE_ID_EXPR
an empty type which causes the call to finish_template_variable from
finish_id_expression_1 to be dead code at template parse time. Thus
we're led into
On Wed, 22 Feb 2023, Marek Polacek wrote:
> In this test, we get a bogus error because we failed to deduce the auto in
> constexpr auto is_pointer_v = is_pointer::value;
> to bool. Then ensure_literal_type_for_constexpr_object thinks the object
> isn't literal and an error is reported.
>
> This
Here we're mishandling the unevaluated array new-expressions due to a
supposed non-constant array size ever since r12-5253-g4df7f8c79835d569,
made us no longer perform constant evaluation of non-manifestly-constant
expressions within unevaluated contexts. This shouldn't make a
difference here
On Sun, 19 Feb 2023, Jason Merrill wrote:
> On 2/15/23 12:11, Patrick Palka wrote:
> > On Wed, 15 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/15/23 09:21, Patrick Palka wrote:
> > > > On Tue, 14 Feb 2023, Jason Merrill wrote:
> > > >
> > > > > On 2/13/23 09:23, Patrick Palka wrote:
> > > > >
On Mon, 20 Feb 2023, Patrick Palka wrote:
> According to [basic.start.static]/2 and [expr.const]/2, a variable
> with static storage duration initialized with a constant initializer
> has constant initialization, and such an initializer is manifestly
> constant-evaluated.
>
> We're already
We should also fold the overall initializer passed to cp_fully_fold_init
with mce_false, which enables folding of the copy-initialization of
'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR).
Unfortunately this doesn't help with direct- or default-initialization
because we
According to [basic.start.static]/2 and [expr.const]/2, a variable
with static storage duration initialized with a constant initializer
has constant initialization, and such an initializer is manifestly
constant-evaluated.
We're already getting this right with copy initialization because in
that
On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote:
> Tested x86_64-pc-linux-gnu. Since this is fixing experimental (C++20)
> functionality, I think it's reasonable to apply now; I'm interested in other
> opinions, and thoughts about the user-facing functionality. I'm thinking to
> make
On Fri, 17 Feb 2023, Patrick Palka wrote:
> On Fri, 17 Feb 2023, Marek Polacek wrote:
>
> > On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
> > > On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> > >
> > > > Here we crash in is_capture_proxy:
> > > >
> > > > /*
On Fri, 17 Feb 2023, Marek Polacek wrote:
> On Fri, Feb 17, 2023 at 03:00:39PM -0500, Patrick Palka wrote:
> > On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> >
> > > Here we crash in is_capture_proxy:
> > >
> > > /* Location wrappers should be stripped or otherwise handled by the
On Fri, 17 Feb 2023, Marek Polacek via Gcc-patches wrote:
> Here we crash in is_capture_proxy:
>
> /* Location wrappers should be stripped or otherwise handled by the
> caller before using this predicate. */
> gcc_checking_assert (!location_wrapper_p (decl));
>
> so fixed as the
This fixes some header-defined functions that are undesirably declared
static and weren't caught by the "^static inline" pattern used in the
previous patch.
gcc/ChangeLog:
* hash-table.h (gt_pch_nx): Remove static.
* lra-int.h (lra_change_class): Likewise.
* recog.h
On Wed, 15 Feb 2023, Jason Merrill wrote:
> On 2/15/23 09:21, Patrick Palka wrote:
> > On Tue, 14 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/13/23 09:23, Patrick Palka wrote:
> > > > [N.B. this is a corrected version of
> > > >
On Tue, 14 Feb 2023, Jason Merrill wrote:
> On 2/13/23 09:23, Patrick Palka wrote:
> > [N.B. this is a corrected version of
> > https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
> >
> > This patch factors out the TYPENAME_TYPE case of tsubst into a separate
> > function
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
Currently when resolving a TYPENAME_TYPE for 'typename T::m' via
make_typename_type, we consider only type bindings of 'm' and ignore
non-type ones. But [temp.res.general]/3 says, in a
[N.B. this is a corrected version of
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607443.html ]
This patch factors out the TYPENAME_TYPE case of tsubst into a separate
function tsubst_typename_type. It also factors out the two tsubst flags
controlling TYPENAME_TYPE substitution,
On Fri, 10 Feb 2023, Patrick Palka wrote:
> On Thu, 9 Feb 2023, Patrick Palka wrote:
>
> > On Thu, 9 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/9/23 09:36, Patrick Palka wrote:
> > > > On Sun, 5 Feb 2023, Jason Merrill wrote:
> > > >
> > > > > On 2/3/23 15:51, Patrick Palka wrote:
> > > > >
On Thu, 9 Feb 2023, Patrick Palka wrote:
> On Thu, 9 Feb 2023, Jason Merrill wrote:
>
> > On 2/9/23 09:36, Patrick Palka wrote:
> > > On Sun, 5 Feb 2023, Jason Merrill wrote:
> > >
> > > > On 2/3/23 15:51, Patrick Palka wrote:
> > > > > On Mon, 30 Jan 2023, Jason Merrill wrote:
> > > > >
> > >
On Thu, 9 Feb 2023, Jason Merrill wrote:
> On 2/9/23 09:36, Patrick Palka wrote:
> > On Sun, 5 Feb 2023, Jason Merrill wrote:
> >
> > > On 2/3/23 15:51, Patrick Palka wrote:
> > > > On Mon, 30 Jan 2023, Jason Merrill wrote:
> > > >
> > > > > On 1/27/23 17:02, Patrick Palka wrote:
> > > > > >
On Thu, 9 Feb 2023, Patrick Palka wrote:
> When substituting into sizeof(expr), tsubst_copy_and_build elides
> substitution into the operand if args is NULL_TREE, and instead
> considers the TREE_TYPE of the operand. But here the (templated)
> operand is a TEMPLATE_ID_EXPR with empty TREE_TYPE,
When substituting into sizeof(expr), tsubst_copy_and_build elides
substitution into the operand if args is NULL_TREE, and instead
considers the TREE_TYPE of the operand. But here the (templated)
operand is a TEMPLATE_ID_EXPR with empty TREE_TYPE, so we can't elide
substitution in this case.
On Sun, 5 Feb 2023, Jason Merrill wrote:
> On 2/3/23 15:51, Patrick Palka wrote:
> > On Mon, 30 Jan 2023, Jason Merrill wrote:
> >
> > > On 1/27/23 17:02, Patrick Palka wrote:
> > > > This PR illustrates that __builtin_is_constant_evaluated currently acts
> > > > as an optimization barrier for
On Sat, 4 Feb 2023, Jason Merrill wrote:
> On 2/4/23 20:41, Jason Merrill wrote:
> > On 2/4/23 20:08, Patrick Palka wrote:
> > > On Sat, 4 Feb 2023, Jason Merrill wrote:
> > >
> > > > On 2/4/23 15:31, Patrick Palka wrote:
> > > > > After r13-5684-g59e0376f607805 the (pruned) callee of a
On Sat, 4 Feb 2023, Jason Merrill wrote:
> On 2/4/23 15:31, Patrick Palka wrote:
> > After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
> > CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
> > This innocent change revealed that cp_tree_equal doesn't
After r13-5684-g59e0376f607805 the (pruned) callee of a non-dependent
CALL_EXPR is a bare FUNCTION_DECL rather than ADDR_EXPR of FUNCTION_DECL.
This innocent change revealed that cp_tree_equal doesn't first check
dependentness of a CALL_EXPR before treating the callee as a dependent
name, which
On Mon, 30 Jan 2023, Jason Merrill wrote:
> On 1/27/23 17:02, Patrick Palka wrote:
> > This patch turns the manifestly_const_eval flag used by the constexpr
> > machinery into a tri-state enum so that we're able to express wanting
> > to fold __builtin_is_constant_evaluated to false via late
On Fri, 3 Feb 2023, Patrick Palka wrote:
> On Mon, 30 Jan 2023, Jason Merrill wrote:
>
> > On 1/27/23 17:02, Patrick Palka wrote:
> > > This PR illustrates that __builtin_is_constant_evaluated currently acts
> > > as an optimization barrier for our speculative constexpr evaluation,
> > > since
On Mon, 30 Jan 2023, Jason Merrill wrote:
> On 1/27/23 17:02, Patrick Palka wrote:
> > This PR illustrates that __builtin_is_constant_evaluated currently acts
> > as an optimization barrier for our speculative constexpr evaluation,
> > since we don't want to prematurely fold the builtin to false
Here the ahead-of-time overload set pruning in finish_call_expr is
unintentionally returning a CALL_EXPR whose pruned callee is wrapped in
an ADDR_EXPR, despite the original callee not being wrapped in an
ADDR_EXPR. This ends up causing a bogus declaration matching error in
the below testcase
Here we're crashing from check_bases_and_members due to
CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning
performed by add_method, should only happen if there is no viable
destructor or the destructor is ambiguous.
This patch fixes this by making check_bases_and_members naturally
In check_methods we're unnecessarily checking satisfaction for all
constructors and assignment operators, even those that don't look like
copy/move special members. In the testcase below this manifests as an
unstable satisfaction error because the satisfaction result is first
determined to be
On Fri, 27 Jan 2023, Patrick Palka wrote:
> On Fri, 27 Jan 2023, Marek Polacek wrote:
>
> > On Fri, Jan 27, 2023 at 05:15:00PM -0500, Patrick Palka wrote:
> > > On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote:
> > >
> > > > Here we crash because a CAST_EXPR, representing T(), doesn't
On Fri, 27 Jan 2023, Marek Polacek wrote:
> On Fri, Jan 27, 2023 at 05:15:00PM -0500, Patrick Palka wrote:
> > On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote:
> >
> > > Here we crash because a CAST_EXPR, representing T(), doesn't have
> > > its operand, and operand_equal_p's
On Thu, 26 Jan 2023, Marek Polacek via Gcc-patches wrote:
> Here we crash because a CAST_EXPR, representing T(), doesn't have
> its operand, and operand_equal_p's STRIP_ANY_LOCATION_WRAPPER doesn't
> expect that. (o_e_p is called from warn_duplicated_cond_add_or_warn.)
>
> In the past we've
On Fri, 27 Jan 2023, Patrick Palka wrote:
> This PR illustrates that __builtin_is_constant_evaluated currently acts
> as an optimization barrier for our speculative constexpr evaluation,
> since we don't want to prematurely fold the builtin to false if the
> expression in question would be later
This patch turns the manifestly_const_eval flag used by the constexpr
machinery into a tri-state enum so that we're able to express wanting
to fold __builtin_is_constant_evaluated to false via late speculative
constexpr evaluation. Of all the entry points to constexpr evaluation
only
This PR illustrates that __builtin_is_constant_evaluated currently acts
as an optimization barrier for our speculative constexpr evaluation,
since we don't want to prematurely fold the builtin to false if the
expression in question would be later manifestly constant evaluated (in
which case it
On Thu, 26 Jan 2023, Patrick Palka wrote:
> On Thu, 26 Jan 2023, Jakub Jelinek wrote:
>
> > On Thu, Jan 26, 2023 at 09:45:35AM -0500, Patrick Palka via Gcc-patches
> > wrote:
> > > > +#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
> > > > +#def
On Thu, 26 Jan 2023, Jakub Jelinek wrote:
> On Thu, Jan 26, 2023 at 09:45:35AM -0500, Patrick Palka via Gcc-patches wrote:
> > > +#define DEFTREECODE(SYM, NAME, TYPE, LENGTH) TYPE,
> > > +#define END_OF_BASE_TREE_CODES tcc_exceptional,
> > > +
> > > +
On Fri, 18 Nov 2022, apinski--- via Gcc-patches wrote:
> From: Andrew Pinski
>
> Since we use C++11 by default now, we can
> use constexpr for some const decls in tree-core.h.
>
> This patch does that and it allows for better optimizations
> of GCC code with checking enabled and without LTO.
>
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 Wed, 5 Oct 2022, Patrick Palka wrote:
> > >
> > > > On Thu, 7 Jul 2022, Jonathan Wakely via Gc
Here we're not clearing DECL_UNINSTANTIATED_TEMPLATE_FRIEND_P for
the instantiated/injected template friend class B, which confuses a
later call to get_originating_module_decl for B. This patch fixes this
by clearing the flag in tsubst_friend_class (as is already done for
template friend
On Mon, 9 Jan 2023, Patrick Palka wrote:
> On Wed, 5 Oct 2022, Patrick Palka wrote:
>
> > On Thu, 7 Jul 2022, Jonathan Wakely via Gcc-patches wrote:
> >
> > > This adds a new built-in to replace the recursive class template
> > > instantiations done by traits such as std::tuple_element and
> >
On Wed, 5 Oct 2022, Patrick Palka wrote:
> On Thu, 7 Jul 2022, Jonathan Wakely via Gcc-patches wrote:
>
> > This adds a new built-in to replace the recursive class template
> > instantiations done by traits such as std::tuple_element and
> > std::variant_alternative. The purpose is to select the
On Fri, 6 Jan 2023, Patrick Palka wrote:
> Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
>
> PR libstdc++/108620
>
> libstdc++-v3/ChangeLog:
>
> * include/bits/utility.h (__cpp_lib_ranges_zip): Define.
> * include/std/ranges (__cpp_lib_ranges_zip): Define.
>
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
PR libstdc++/108620
libstdc++-v3/ChangeLog:
* include/bits/utility.h (__cpp_lib_ranges_zip): Define.
* include/std/ranges (__cpp_lib_ranges_zip): Define.
(__cpp_lib_ranges_chunk): Define.
On Thu, 5 Jan 2023, Patrick Palka wrote:
> When tentatively parsing what is really an elaborated-type-specifier
> first as a class-specifier, we may form a CPP_TEMPLATE_ID token that
> later gets reused in the fallback parse if the tentative parse fails.
> These special tokens also capture the
When tentatively parsing what is really an elaborated-type-specifier
first as a class-specifier, we may form a CPP_TEMPLATE_ID token that
later gets reused in the fallback parse if the tentative parse fails.
These special tokens also capture the access checks that have been
deferred while parsing
We typically ignore mark_used failure when in a non-SFINAE context for
sake of better error recovery. But in mark_single_function we're
instead ignoring mark_used failure in a SFINAE context, which ends up
causing the second static_assert here to incorrectly fail.
Bootstrapped and regtested on
On Thu, 22 Dec 2022, Patrick Palka wrote:
> On Thu, 22 Dec 2022, Jason Merrill wrote:
>
> > On 12/22/22 16:41, Patrick Palka wrote:
> > > On Thu, 22 Dec 2022, Jason Merrill wrote:
> > >
> > > > On 12/22/22 11:31, Patrick Palka wrote:
> > > > > On Wed, 21 Dec 2022, Jason Merrill wrote:
> > > > >
On Thu, 22 Dec 2022, Jason Merrill wrote:
> On 12/22/22 16:41, Patrick Palka wrote:
> > On Thu, 22 Dec 2022, Jason Merrill wrote:
> >
> > > On 12/22/22 11:31, Patrick Palka wrote:
> > > > On Wed, 21 Dec 2022, Jason Merrill wrote:
> > > >
> > > > > On 12/21/22 09:52, Patrick Palka wrote:
> > > >
On Thu, 22 Dec 2022, Jason Merrill wrote:
> On 12/22/22 11:31, Patrick Palka wrote:
> > On Wed, 21 Dec 2022, Jason Merrill wrote:
> >
> > > On 12/21/22 09:52, Patrick Palka wrote:
> > > > Here during ahead of time checking of C{}, we indirectly call get_nsdmi
> > > > for C::m from
On Thu, 15 Dec 2022, Jason Merrill wrote:
> On 12/15/22 14:31, Patrick Palka wrote:
> > On Thu, 15 Dec 2022, Patrick Palka wrote:
> >
> > > On Thu, 15 Dec 2022, Jason Merrill wrote:
> > >
> > > > On 12/12/22 12:20, Patrick Palka wrote:
> > > > > When instantiating a constrained hidden template
On Wed, 21 Dec 2022, Jason Merrill wrote:
> On 12/21/22 09:52, Patrick Palka wrote:
> > Here during ahead of time checking of C{}, we indirectly call get_nsdmi
> > for C::m from finish_compound_literal, which in turn calls
> > break_out_target_exprs for C::m's (non-templated) initializer, during
On Wed, 21 Dec 2022, Patrick Palka wrote:
> Here during ahead of time checking of C{}, we indirectly call get_nsdmi
> for C::m from finish_compound_literal, which in turn calls
> break_out_target_exprs for C::m's (non-templated) initializer, during
> which we end up building a call to A::~A and
Here during ahead of time checking of C{}, we indirectly call get_nsdmi
for C::m from finish_compound_literal, which in turn calls
break_out_target_exprs for C::m's (non-templated) initializer, during
which we end up building a call to A::~A and checking expr_noexcept_p
for it (from
Unfortunately the extract_autos_r fix in r13-4799-ga7c8036b26082d is
derailed by the fact that walk_tree_1 currently walks the elements of a
TREE_VEC in reverse, which means for A in the below testcase
extract_autos_r ends up adjusting the TEMPLATE_TYPE_IDX of the first
auto rather than the second
On Mon, 19 Dec 2022, Jason Merrill wrote:
> On 12/6/22 13:35, Patrick Palka wrote:
> > This patch fixes some issues with substitution into a C++20 template
> > parameter object wrapper:
> >
> > * The first testcase demonstrates a situation where the same_type_p
> >assert in relevant case of
On Tue, 6 Dec 2022, Patrick Palka wrote:
> On Tue, 6 Dec 2022, Patrick Palka wrote:
>
> > This patch fixes some issues with substitution into a C++20 template
> > parameter object wrapper:
> >
> > * The first testcase demonstrates a situation where the same_type_p
> > assert in relevant case
On Wed, 7 Dec 2022, Patrick Palka wrote:
> In extract_autos_r, we need to reset TYPE_CANONICAL for the template
> type parameter after adjusting its index, otherwise we end up with a
> comptypes ICE for the below testcase. Note that such in-place type
> adjustment isn't generallly safe to do
On Fri, 16 Dec 2022, Jason Merrill wrote:
> On 12/16/22 11:45, Patrick Palka wrote:
> > Here we're rejecting the use of the captured 't' (of empty type) as a
> > template argument ultimately because convert_nontype_argument checks
> > potentiality using is_constant_expression which returns false
Here we're rejecting the use of the captured 't' (of empty type) as a
template argument ultimately because convert_nontype_argument checks
potentiality using is_constant_expression which returns false for
captured variables since want_rval=false. But in this case an
lvalue-to-rvalue conversion of
On Thu, 15 Dec 2022, Patrick Palka wrote:
> On Thu, 15 Dec 2022, Jason Merrill wrote:
>
> > On 12/12/22 12:20, Patrick Palka wrote:
> > > When instantiating a constrained hidden template friend, we need to
> > > substitute into its constraints for sake of declaration matching.
> >
> > Hmm, we
201 - 300 of 1377 matches
Mail list logo
