Here we're failing to communicate to cp_finish_decl from tsubst_expr
that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING
flag), which causes do_class_deduction to always consider explicit
deduction guides when performing CTAD for a templated variable initializer.
We could fi
On Fri, 4 Mar 2022, Jason Merrill wrote:
> On 3/4/22 14:24, Patrick Palka wrote:
> > Here we're failing to communicate to cp_finish_decl from tsubst_expr
> > that we're in a copy-initialization context (via the LOOKUP_ONLYCONVERTING
> > flag), which causes do_class_deduction to always consider exp
instantiate_non_dependent_expr_sfinae instantiates only potentially
constant expressions, but when processing a non-dependent decltype
operand we want to instantiate it even if it's non-constant since
such non-dependent decltype is always resolved ahead of time.
Currently finish_decltype_type uses
On Mon, 7 Mar 2022, Jason Merrill wrote:
> On 3/7/22 10:47, Patrick Palka wrote:
> > On Fri, 4 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/4/22 14:24, Patrick Palka wrote:
> > > > Here we're failing to communicate to cp_finish_decl from tsubst_expr
> > > > that we're in a copy-initialization co
On Mon, 7 Mar 2022, Jason Merrill wrote:
> On 3/7/22 14:41, Patrick Palka wrote:
> > instantiate_non_dependent_expr_sfinae instantiates only potentially
> > constant expressions
>
> Hmm, that now strikes me as a problematic interface, as we don't know whether
> what we get back is template or
On Tue, 8 Mar 2022, Jason Merrill wrote:
> On 3/8/22 11:36, Patrick Palka wrote:
> > On Mon, 7 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/7/22 10:47, Patrick Palka wrote:
> > > > On Fri, 4 Mar 2022, Jason Merrill wrote:
> > > >
> > > > > On 3/4/22 14:24, Patrick Palka wrote:
> > > > > > Here
On Tue, 8 Mar 2022, Jason Merrill wrote:
> On 3/8/22 12:54, Patrick Palka wrote:
> >
> >
> > On Mon, 7 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/7/22 14:41, Patrick Palka wrote:
> > > > instantiate_non_dependent_expr_sfinae instantiates only potentially
> > > > constant expressions
> > >
>
On Tue, 8 Mar 2022, Jason Merrill wrote:
> On 3/8/22 14:38, Patrick Palka wrote:
> > On Tue, 8 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/8/22 11:36, Patrick Palka wrote:
> > > > On Mon, 7 Mar 2022, Jason Merrill wrote:
> > > >
> > > > > On 3/7/22 10:47, Patrick Palka wrote:
> > > > > > On Fr
On Tue, 8 Mar 2022, Jason Merrill wrote:
> On 3/2/22 14:32, Patrick Palka wrote:
> > In order to be able to perform CTAD for a dependently-scoped template
> > such as A::B in the testcase below, we need to permit a
> > typename-specifier to resolve to a template as per [dcl.type.simple]/2,
> > at
On Wed, Mar 9, 2022 at 8:54 AM Mikael Morin wrote:
>
> Hello,
>
> Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
> > Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in release
> > branch numbers, where
> > a leading zero does not occur.
> >
> Note that you also
We need to be explicit about narrowing conversions from uint128_t since,
on targets that lack __int128, this type is defined as an integer-class
type that is only _explicitly_ convertible to the builtin integer types.
This issue was latent until r12-7563-ge32869a17b788b made the frontend
correctly
On Wed, 9 Mar 2022, Jason Merrill wrote:
> On 3/1/22 18:08, Patrick Palka wrote:
> > A well-formed call to std::move/forward is equivalent to a cast, but the
> > former being a function call means it comes with bloated debug info, which
> > persists even after the call has been inlined away, for a
On Wed, 9 Mar 2022, Jason Merrill wrote:
> On 3/9/22 10:39, Patrick Palka wrote:
> > On Tue, 8 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/2/22 14:32, Patrick Palka wrote:
> > > > In order to be able to perform CTAD for a dependently-scoped template
> > > > such as A::B in the testcase below, w
When shortcutting bad conversions during overload resolution, we assume
argument conversions get computed in sequential order and that therefore
we just need to inspect the last conversion in order to determine if _any_
conversion is missing. But this assumption turns out to be false for
templates
On Thu, 10 Mar 2022, Jason Merrill wrote:
> On 2/16/22 15:56, Patrick Palka wrote:
> > On Tue, 15 Feb 2022, Jason Merrill wrote:
> >
> > > On 2/14/22 11:32, Patrick Palka wrote:
> > > > Here the template context for the atomic constraint has two levels of
> > > > template arguments, but since i
On Thu, 10 Mar 2022, Jason Merrill wrote:
> On 3/1/22 00:10, Patrick Palka wrote:
> > On Tue, 19 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/13/21 12:05 PM, Patrick Palka wrote:
> > > > In the below testcase, the expression of the atomic constraint after
> > > > substitution is (int *) NON_LVAL
On Fri, 11 Mar 2022, Jonathan Wakely wrote:
> Patrick, I think this is right, but please take a look to double check.
>
> I think we should fix the feature-test macro conditions for gcc-11 too,
> although it's a bit more complicated there. It should depend on IEEE
> float and double *and* useloca
On Fri, 11 Mar 2022, Jason Merrill wrote:
> On 3/10/22 11:27, Patrick Palka wrote:
> > On Wed, 9 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/1/22 18:08, Patrick Palka wrote:
> > > > A well-formed call to std::move/forward is equivalent to a cast, but the
> > > > former being a function call mea
When a lookup is ambiguous, lookup_member still attempts to check
access of the first member found before diagnosing the ambiguity and
erroring out, which may cause us to issue an extraneous access error
in case of ambiguous lookup as in the testcase below (for B1::foo).
This patch fixes this by s
On Mon, 14 Mar 2022, Jason Merrill wrote:
> On 3/14/22 13:13, Patrick Palka wrote:
> > On Fri, 11 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/10/22 11:27, Patrick Palka wrote:
> > > > On Wed, 9 Mar 2022, Jason Merrill wrote:
> > > >
> > > > > On 3/1/22 18:08, Patrick Palka wrote:
> > > > > > A
On Mon, 14 Mar 2022, Jonathan Wakely wrote:
> On Mon, 14 Mar 2022 at 14:17, Patrick Palka via Libstdc++
> wrote:
> >
> > On Fri, 11 Mar 2022, Jonathan Wakely wrote:
> >
> > > Patrick, I think this is right, but please take a look to double check.
> > >
> > > I think we should fix the feature-test
On Tue, 15 Mar 2022, Jason Merrill wrote:
> On 3/15/22 10:03, Patrick Palka wrote:
> > On Mon, 14 Mar 2022, Jason Merrill wrote:
> >
> > > On 3/14/22 13:13, Patrick Palka wrote:
> > > > On Fri, 11 Mar 2022, Jason Merrill wrote:
> > > >
> > > > > On 3/10/22 11:27, Patrick Palka wrote:
> > > > > >
As a followup to r12-7656-gffe9c0a0d3564a, this minor patch condenses
the handling of ambiguity and access w.r.t. the value of 'protect' so
that it more clearly matches the function comment.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
On Tue, Mar 1, 2022 at 8:13 AM Patrick Palka wrote:
>
> On Thu, Feb 17, 2022 at 3:24 PM Patrick Palka wrote:
> >
> > name_lookup::search_unqualified uses a statically allocated vector
> > in order to avoid repeated reallocation, under the assumption that
> > the function can't be called recursive
On Mon, 21 Mar 2022, Jason Merrill via Gcc-patches wrote:
> Our C++20 designated initializer handling was broken with members of class
> type; we would find the relevant member and then try to find a member of
> the member with the same name. Or we would sometimes ignore the designator
> entirely
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,
which means cp_unevaluated_operand remains set during mark_used for
A::A() and so we never synthesize it. Later constant evaluation for
the substituted te
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,
> which means cp_unevaluated_operand remains set during mark_used for
> A::A() and so we never synthesize it
On Wed, 23 Mar 2022, Jason Merrill via Gcc-patches wrote:
> Here, DECL_DEPENDENT_P was false for the second using because Row is
> "the current instantiation", so lookup succeeds. But since Row itself has a
> dependent using-decl for operator(), the set of functions imported by the
> second using
Here we weren't respecting SFINAE when evaluating a substituted call to
a consteval function, which caused us to reject the new testcase below.
This patch fixes this by making build_over_call use the SFINAE-friendly
version of cxx_constant_value.
This change causes us to no longer diagnose ahead o
On Thu, 17 Mar 2022, Patrick Palka wrote:
> On Tue, Mar 1, 2022 at 8:13 AM Patrick Palka wrote:
> >
> > On Thu, Feb 17, 2022 at 3:24 PM Patrick Palka wrote:
> > >
> > > name_lookup::search_unqualified uses a statically allocated vector
> > > in order to avoid repeated reallocation, under the ass
When an if-stmt is deemed non-constant because both of its branches are
non-constant, we issue a rather generic error which, given that it points
to the 'if' token, misleadingly suggests the condition is at fault:
constexpr-105050.C:8:3: error: expression ‘’ is not a constant
expression
8
When constructing the builtin operator->* candidate set according to
the available conversion functions for each operand type, we end up
considering a candidate with C1=T (a TEMPLATE_TYPE_PARM) and C2=F,
during which we crash from lookup_base because dependent_type_p sees
a TEMPLATE_TYPE_PARM when
We weren't rejecting a concept declared with multiple template
parameter lists.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/105067
gcc/cp/ChangeLog:
* pt.cc (finish_concept_definition): Require that a concept is
declared with ex
Here during declaration matching for the two constrained template
friends, we crash from maybe_substitute_reqs_for because the second
friend doesn't yet have DECL_TEMPLATE_INFO set (we're being called
indirectly from push_template_decl).
As far as I can tell, this situation happens only when decla
We no longer emit a bogus warning for the below testcase after
r11-3266-g4839de55e2c986.
Tested on x86_64-pc-linux-gnu, committed to trunk as obvious.
PR c++/71637
gcc/testsuite/ChangeLog:
* c-c++-common/Wmisleading-indentation-6.c: New test.
---
.../c-c++-common/Wmisleading-in
Here we're crashing when diagnosing a failed __is_constructible constraint
because diagnose_atomic_constraint don't know how to diagnose a trait
that diagnose_trait_expr doesn't specifically handle. This patch fixes
this by falling through to the default case in this situation.
Bootstrapped and r
On Tue, 29 Mar 2022, Jason Merrill wrote:
> On 3/29/22 15:22, Patrick Palka wrote:
> > Here we're crashing when diagnosing a failed __is_constructible constraint
> > because diagnose_atomic_constraint don't know how to diagnose a trait
> > that diagnose_trait_expr doesn't specifically handle. Thi
Here deduction for the P/A pair V/a spuriously fails with
types ‘A’ and ‘const A’ have incompatible cv-qualifiers
because the argument type is const, whereas the parameter type is
non-const.
Since the type of an NTTP is always cv-unqualified, it seems natural to
ignore cv-qualifiers on the arg
On Wed, 30 Mar 2022, Jason Merrill via Gcc-patches wrote:
> The recent change to reject __is_constructible for nested classes with DMI
> is breaking some code loudly that was previously only silently broken.
> Let's allow simple cases by immediately parsing DMI that do no name lookup;
> then being
An implicit guide already inherits the (rewritten) constraints of the
constructor. Thus it seems natural that the guide must also inherit
the constraints of the class template, since a constructor's constraints
might assume the class's constraints are satisfied, and therefore
checking these two se
We were attempting to issue a -Wctad-maybe-unsupported warning even when
complain=tf_none, which led to a crash in the first testcase below and a
bogus error during SFINAE in the second testcase.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/11?
PR c++/105
Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an
ARGUMENT_PACK_SELECT (which just resolves to the parameter pack Ts).
Then when looking up the resulting
On Tue, Apr 12, 2022 at 12:33 PM Jason Merrill wrote:
>
> On 4/12/22 12:17, Patrick Palka wrote:
> > Here after dependent substitution of {Ts...} into the alias 'wrap',
> > since we never partially instantiate a requires-expr, we end up with a
> > requires-expr whose REQUIRES_EXPR_EXTRA_ARGS conta
On Wed, Feb 16, 2022 at 2:47 PM Patrick Palka wrote:
>
> On Tue, 15 Feb 2022, Jason Merrill wrote:
>
> > On 2/15/22 17:00, Patrick Palka wrote:
> > > On Tue, 15 Feb 2022, Jason Merrill wrote:
> > >
> > > > On 2/15/22 15:13, Patrick Palka wrote:
> > > > > On Tue, 15 Feb 2022, Patrick Palka wrote:
>
This applies the following optimizations to the integer std::from_chars
implementation:
1. Use a lookup table for converting an alphanumeric digit to its
base-36 value instead of using a range test (for 0-9) and switch
(for a-z and A-Z). The table is constructed using a C++14
con
On Thu, 14 Apr 2022, Patrick Palka wrote:
> This applies the following optimizations to the integer std::from_chars
> implementation:
>
> 1. Use a lookup table for converting an alphanumeric digit to its
> base-36 value instead of using a range test (for 0-9) and switch
> (for a-z and
Tested on x86_64-pc-linux-gnu, does this look OK for trunk and 11/10
once the branch is unfrozen?
PR libstdc++/104858
libstdc++-v3/ChangeLog:
* include/bits/ranges_algo.h (__minmax_fn): Avoid dereferencing
__first twice at the start.
* testsuite/25_algorithms/minm
This reimplements std::has_single_bit using the well-known bit-twiddilng
trick[1], which is much faster than popcount on x86_64.
Note that when __x is signed and maximally negative then this
implementation invokes UB due to signed overflow, whereas the previous
implementation would return true. T
On Thu, Apr 14, 2022 at 2:59 PM Jonathan Wakely wrote:
>
> On Thu, 14 Apr 2022 at 19:17, Patrick Palka via Libstdc++
> wrote:
> >
> > This reimplements std::has_single_bit using the well-known bit-twiddilng
> > trick[1], which is much faster than popcount on x86_64.
>
> Is that always true for al
Assertions were originally enabled in the compiled-in floating-point
std::to_chars implementation to help shake out any bugs, but they
apparently impose a significant performance penalty, in particular for
the hex formatting which is around 25% slower with assertions enabled.
This seems too high of
On Thu, 14 Apr 2022, Jonathan Wakely wrote:
> On Thu, 14 Apr 2022 at 16:21, Patrick Palka via Libstdc++
> wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk and 11/10
> > once the branch is unfrozen?
> >
> > PR libstdc++/104858
> >
> > libstdc++-v3/ChangeLog:
> >
>
On Sun, Apr 17, 2022 at 6:24 PM Jason Merrill wrote:
>
> On 4/15/22 07:22, Jakub Jelinek wrote:
> > Hi!
> >
> > The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
> > PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
> > (variable, TARGET_EXPR slot, ...) fro
At the first iteration of __from_chars_pow2_base's main loop, we need
to remember the value of the leading significant digit for sake of the
overflow check at the end of the function (for bases other than 2).
This patch manually unrolls this first iteration so as to not encumber
the entire loop wi
This makes the initializer for __table in __from_chars_alnum_to_val
dependent in an artificial way, which works around the modules testsuite
ICE reported in PR105297 by preventing the initializer from getting
evaluated at parse time.
Compared to the alternative workaround of using a non-local clas
In starts_with_ci and in __floating_from_chars_hex's inf/nan handling,
we were assuming that the letters are contiguous and that 'A' + 32 == 'a'
which is true for ASCII but not for other character encodings. This
patch fixes starts_with_ci by using a constexpr lookup table that maps
uppercase lett
Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing
(respectively) on two testcases that we used to accept in C++17 mode.
Both testcases declare partial specializations for which the primary
template contains an NTTP with dependent type, but the correctness of
these partial specia
Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing
(respectively) on two testcases that we used to accept in C++17 mode.
Both testcases declare partial specializations for which the primary
template contains an NTTP with dependent type, but the correctness of
these partial specia
Here we're crashing from verify_sequence_points for this requires-expr
condition because it contains a templated CAST_EXPR with empty operand,
and verify_tree doesn't ignore this empty operand only because the
manual tail recursion that it perform for unary expression trees skips
the NULL test.
Bo
Whoops, this patch is identical to
https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593502.html that
I sent about an hour ago, sorry for the noise.
On Fri, Apr 22, 2022 at 2:33 PM Patrick Palka wrote:
>
> Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing
> (respectively) o
We're incorrectly rejecting the below testcase during template argument
coercion because invalid_nontype_parm_type_p returns true for
DEPENDENT_OPERATOR_TYPE.
This patch fixes this by partially rewriting invalid_nontype_parm_type_p
in terms of WILDCARD_TYPE_P, of which DEPENDENT_OPERATOR_TYPE is o
On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely wrote:
>
> Tested x86_64-linux, pushed to trunk.
>
>
> Instead of hardcoded preprocessor conditionals with explicit target
> checks, just rely on the fact that __BYTE_ORDER__ is always defined by
> GCC.
Thanks a lot for fixing these! I apparently m
On Tue, 18 Jan 2022, Patrick Palka wrote:
> On Tue, Jan 18, 2022 at 5:12 AM Jonathan Wakely wrote:
> >
> > Tested x86_64-linux, pushed to trunk.
> >
> >
> > Instead of hardcoded preprocessor conditionals with explicit target
> > checks, just rely on the fact that __BYTE_ORDER__ is always defined
On Mon, Jan 3, 2022 at 10:24 AM Patrick Palka wrote:
>
> On Wed, 22 Dec 2021, Jason Merrill wrote:
>
> > On 12/21/21 14:08, Patrick Palka wrote:
> > > On Tue, Dec 21, 2021 at 2:03 PM Patrick Palka wrote:
> > > >
> > > > On Wed, Jun 30, 2021 at 4:23 PM Jason Merrill wrote:
> > > > >
> > > > > On
Here we're emitting a bogus error during ahead of time evaluation of a
non-dependent immediate member function call such as a.f(args) because
the defacto templated form for such a call is (a.f)(args) but we're
trying to evaluate it using the intermediate CALL_EXPR built by
build_over_call, which ha
On Wed, 19 Jan 2022, Jason Merrill wrote:
> On 1/3/22 10:24, Patrick Palka wrote:
> > On Wed, 22 Dec 2021, Jason Merrill wrote:
> >
> > > On 12/21/21 14:08, Patrick Palka wrote:
> > > > On Tue, Dec 21, 2021 at 2:03 PM Patrick Palka wrote:
> > > > >
> > > > > On Wed, Jun 30, 2021 at 4:23 PM Jaso
We accept this testcase after r12-6773 ("CTAD inside alias template").
PR c++/103631
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/nontype-class51.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/nontype-class51.C | 26
1 file changed, 26 insertions(+)
create mode 100
Here the call to the &&-qualified toLower() is incorrectly rejected
because the object expression is deemed to be an lvalue, even though it's
really a prvalue. The object expression, instance()->applicationName(),
is expressed as an INDIRECT_REF of a COMPOUND_EXPR
*(*instance ();, &TARGET_EXPR
Avoid using the macro current_template_depth, which expands to an
expression in terms of __FUNCTION__, within the signature of a function.
Clang warns about this and MSVC rejects it.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/104197
gcc/cp/Chan
On Sun, Jan 23, 2022 at 5:53 PM Jonathan Wakely via Gcc-patches
wrote:
>
> Tested powerpc64le-linux, pushed to trunk.
>
>
> We can use the new from_chars implementation when long double and double
> have the same representation.
I suppose we should also update to sync the conditions that
define
Here when attempting to use B's implicitly deleted default constructor,
mark_used rightfully returns false, but for the wrong reason: it
tries to instantiate the implicit noexcept specifier, which only
silently fails because get_defaulted_eh_spec suppresses diagnostics
for deleted functions. This
On Tue, 25 Jan 2022, Patrick Palka wrote:
> Here when attempting to use B's implicitly deleted default constructor,
> mark_used rightfully returns false, but for the wrong reason: it
> tries to instantiate the implicit noexcept specifier, which only
> silently fails because get_defaulted_eh_spec s
In the nested_name_specifier branch within cp_parser_class_head, we need
to update TYPE with the result of maybe_process_partial_specialization
just like we do in the template_id_p branch.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/92944
gcc/cp
On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
>
> On 1/19/22 11:15, Patrick Palka wrote:
> > Here we're emitting a bogus error during ahead of time evaluation of a
> > non-dependent immediate member function call such as a.f(args) because
> > the defacto templated form for such a call is (a
On Wed, 26 Jan 2022, Patrick Palka wrote:
> On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
> >
> > On 1/19/22 11:15, Patrick Palka wrote:
> > > Here we're emitting a bogus error during ahead of time evaluation of a
> > > non-dependent immediate member function call such as a.f(args) because
On Wed, 26 Jan 2022, Patrick Palka wrote:
> On Wed, 26 Jan 2022, Patrick Palka wrote:
>
> > On Wed, Jan 19, 2022 at 2:19 PM Jason Merrill wrote:
> > >
> > > On 1/19/22 11:15, Patrick Palka wrote:
> > > > Here we're emitting a bogus error during ahead of time evaluation of a
> > > > non-dependent
When deducing the type of a variable template specialization with a
constrained auto type, we might need the template arguments for
satisfaction in case the constraint is dependent.
Bootstrapped and reegtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 11?
PR c++/1033
On Thu, 27 Jan 2022, Patrick Palka wrote:
> When deducing the type of a variable template specialization with a
> constrained auto type, we might need the template arguments for
> satisfaction in case the constraint is dependent.
It looks like templated static data members need similar treatment.
Here we're emitting a -Wignored-qualifiers warning for an
intermediate compiler-generated cast of 0 to 'method-type* const'
as part of value initialization of a const pmf. This patch
suppresses the warning by stripping cv-quals from this pointer
type before performing the cast.
Bootstrapped and r
Here during deduction guide generation for the nested class template
B::C, the computation of outer_targs yields the template
arguments relative to the primary template for B (i.e. {char(int)})
but what we really what is those relative to the enclosing scope, the
partial specialization of B (i.e. {
On Mon, Jan 31, 2022 at 11:07 AM Patrick Palka wrote:
>
> Here during deduction guide generation for the nested class template
> B::C, the computation of outer_targs yields the template
> arguments relative to the primary template for B (i.e. {char(int)})
> but what we really what is those relativ
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
PR c++/104291
gcc/cp/ChangeLog:
* pt.cc (for_each_template_parm_r) : Don't
walk subtrees if !include_nondeduced_p. Simplify given that
cp_walk_subtrees already walks TYPE_PTRMEMFUNC_F
Here we're crashing during satisfaction of the lambda's placeholder type
constraints because the constraints depend on the template arguments
from the enclosing scope, which aren't a part of the lambda's
DECL_TI_ARGS. So when inside a lambda, do_auto_deduction needs to add
the "regenerating" templ
The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
template arguments before calling iterative_hash_template_arg and
template_args_equal, which would otherwise crash.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk and perhaps 11?
PR c++/10370
On Wed, 2 Feb 2022, Patrick Palka wrote:
> Here we're crashing during satisfaction of the lambda's placeholder type
> constraints because the constraints depend on the template arguments
> from the enclosing scope, which aren't a part of the lambda's
> DECL_TI_ARGS. So when inside a lambda, do_au
Here a stale value of TYPE_DEPENDENT_P/_P_VALID for f's function
type after replacing its DEFERRED_NOEXCEPT with its parsed (dependent)
noexcept-spec leads us to try to instantiate g's noexcept-spec (which
incorrectly appears non-dependent) ahead of time, causing an ICE.
This patch fixes this by c
On Wed, 2 Feb 2022, Jason Merrill wrote:
> On 2/2/22 12:09, Patrick Palka wrote:
> > The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
> > template arguments before calling iterative_hash_template_arg and
> > template_args_equal, which would otherwise crash.
>
> Maybe we should ha
On Wed, 2 Feb 2022, Jason Merrill wrote:
> On 2/2/22 13:21, Patrick Palka wrote:
> > On Wed, 2 Feb 2022, Patrick Palka wrote:
> >
> > > Here we're crashing during satisfaction of the lambda's placeholder type
> > > constraints because the constraints depend on the template arguments
> > > from
When synthesizing a defaulted comparison op from
maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
noexcept-spec afterwards.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk and perhaps 11?
PR c++/96242
gcc/cp/ChangeLog:
* pt.c
On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote:
>
> On 2/3/22 12:04, Patrick Palka wrote:
> > On Wed, 2 Feb 2022, Jason Merrill wrote:
> >
> >> On 2/2/22 12:09, Patrick Palka wrote:
> >>> The satisfaction cache needs to look through ARGUMENT_PACK_SELECT
> >>> template arguments before calling
On Thu, 3 Feb 2022, Jason Merrill wrote:
> On 2/3/22 14:58, Patrick Palka wrote:
> > When synthesizing a defaulted comparison op from
> > maybe_instantiate_noexcept, we seem to be forgetting to instantiate the
> > noexcept-spec afterwards.
>
> Hmm, there shouldn't be any need to instantiate the n
On Thu, 3 Feb 2022, Jason Merrill wrote:
> On 2/3/22 16:06, Patrick Palka wrote:
> > On Thu, 3 Feb 2022, Jason Merrill wrote:
> >
> > > On 2/3/22 14:58, Patrick Palka wrote:
> > > > When synthesizing a defaulted comparison op from
> > > > maybe_instantiate_noexcept, we seem to be forgetting to in
Here constant evaluation of the atomic constraint use_func_v with T=int
sensibly yields an INTEGER_CST of type const bool, but the assert in
satisfaction_value expects unqualified bool. Let's just relax the
assert to accept cv-qualified bool more generally.
Bootstrapped and regtested on x86_64-pc
The fail-fast predicate uses_deducible_template_parms used by
unify_one_argument is neglecting to look inside the noexcept-spec of a
function type, and this causes deduction to fail for the below testcase
since the noexcept-spec is the only part of the type which contains a
deducible template param
On Thu, 3 Feb 2022, Jason Merrill wrote:
> On 2/3/22 15:55, Patrick Palka wrote:
> > On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote:
> > >
> > > On 2/3/22 12:04, Patrick Palka wrote:
> > > > On Wed, 2 Feb 2022, Jason Merrill wrote:
> > > >
> > > > > On 2/2/22 12:09, Patrick Palka wrote:
> >
In filter_memfn_lookup, we weren't correctly recognizing and matching up
member functions introduced via a non-dependent using-decl. This caused
us to crash in the below testcases in which we correctly pruned the
overload set for the non-dependent call ahead of time, but then at
instantiation time
On Wed, 9 Feb 2022, Jason Merrill wrote:
> On 2/9/22 10:45, Patrick Palka wrote:
> > In filter_memfn_lookup, we weren't correctly recognizing and matching up
> > member functions introduced via a non-dependent using-decl. This caused
> > us to crash in the below testcases in which we correctly pr
On Wed, 9 Feb 2022, Jason Merrill wrote:
> On 2/9/22 11:36, Patrick Palka wrote:
> > On Wed, 9 Feb 2022, Jason Merrill wrote:
> >
> > > On 2/9/22 10:45, Patrick Palka wrote:
> > > > In filter_memfn_lookup, we weren't correctly recognizing and matching up
> > > > member functions introduced via a
r12-1606 bumped the value of __cpp_lib_ranges defined in ,
but this macro is also defined in , so it needs to
be updated there as well.
PR libstdc++/103904
libstdc++-v3/ChangeLog:
* include/bits/ranges_cmp.h (__cpp_lib_ranges): Adjust value.
(cherry picked from commit 12bdd39755
The primary template for _CachedPosition is a dummy implementation for
non-forward ranges, the iterators for which generally can't be cached.
Because this implementation doesn't actually cache anything, _M_has_value
is defined to be false and so calls to _M_get (which are always guarded
by _M_has_v
Tested on x86_64-pc-linux-gnu, does this look OK for the 11 branch?
The backport to the 10 branch hasn't been started yet, I figured it'd
be good to first get the 11 backport right then base the 10 backport
on the 11 one.
NB: This backport of r12-1606 to the 11 branch deliberately omits parts
of P
301 - 400 of 1378 matches
Mail list logo
