On Wed, Feb 16, 2022 at 2:56 PM 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 it depends only on the innermost argument
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 recursively. With modules however,
> this assumption turns out to be
This improves diagnostic quality for unsatisfied atomic constraints
that consist of a fold expression, e.g. in concepts/diagnostics3.C:
.../diagnostic3.C:10:22: note: the expression ‘(foo && ...) [with Ts =
{int, char}]’ evaluated to ‘false’
10 | requires (foo && ...)
|
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_LVALUE_EXPR <1> != 0B which is not a C++
> > constant expression, but its TREE_CONSTANT flag is set (from
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
libstdc++-v3/ChangeLog:
* include/bits/ranges_base.h (__detail::__is_initializer_list):
Define.
(viewable_range): Adjust as per P2415R2.
* include/std/ranges (owning_view): Define as per P2415R2.
The a1 and a2 case were fixed (by diagnosing the invalid expression)
with r11-434, and the a3 case with r8-7625.
PR c++/85493
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype80.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/decltype80.C | 16
1 file changed, 16
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 recursively. With modules however,
this assumption turns out to be false, and search_unqualified can
be called recursively as
Here when instantiating the noexcept-spec we fail to resolve the
implicit object parameter for the call A::f() ultimately because
maybe_instantiate_noexcept sets current_class_ptr/ref to the dependent
'this' (of type B) rather than the specialized 'this' (of type B).
This ends up causing
In finish_compound_literal, we perform non-dependent expr folding before
calling check_narrowing (ever since r9-5973). But ever since r10-7096,
check_narrowing also performs non-dependent expr folding of its own.
This double folding cause tsubst to see non-templated trees during the
second
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 it depends only on the innermost argument
> > T we use a single-level argument vector during substitution
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:
> > > >
> > > > > Here we're crashing from
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:
> >
> > > Here we're crashing from potential_constant_expression because it tries
> > > to perform trial evaluation of the first operand '(bool)__r' of the
> > >
On Tue, 15 Feb 2022, Patrick Palka wrote:
> Here we're crashing from potential_constant_expression because it tries
> to perform trial evaluation of the first operand '(bool)__r' of the
> conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but
> cxx_eval_constant_expression ICEs on
Here we're crashing from potential_constant_expression because it tries
to perform trial evaluation of the first operand '(bool)__r' of the
conjunction (which is overall wrapped in a NON_DEPENDENT_EXPR), but
cxx_eval_constant_expression ICEs on unhandled trees (of which CAST_EXPR
is one).
Since
On Mon, 14 Feb 2022, Patrick Palka wrote:
> Here the template context for the atomic constraint has two levels of
> template arguments, but since it depends only on the innermost argument
> T we use a single-level argument vector during substitution into the
> constraint (built by
Here the template context for the atomic constraint has two levels of
template arguments, but since it depends only on the innermost argument
T we use a single-level argument vector during substitution into the
constraint (built by get_mapped_args). We eventually pass this vector
to
On Fri, 11 Feb 2022, Patrick Palka wrote:
> In the P2325R3 backport r11-9555 the relaxation of the constraints on
> the partial specialization of __box (which is semantically equivalent to
> the primary template, only more space efficient) means some
> specializations of __box will now use the
In the P2325R3 backport r11-9555 the relaxation of the constraints on
the partial specialization of __box (which is semantically equivalent to
the primary template, only more space efficient) means some
specializations of __box will now use the partial specialization instead
of the primary
On Thu, 10 Feb 2022, Patrick Palka wrote:
> 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
On Thu, 10 Feb 2022, Patrick Palka wrote:
> 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
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
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
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
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
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
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
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:
>
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
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
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
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
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
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:
*
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
> > >
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
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
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,
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
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"
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
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
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.
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
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
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
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
> > > >
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)
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
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
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
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 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
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
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 ();, _EXPR ;);
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
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
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
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
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 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
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
On Mon, Jan 17, 2022 at 5:54 AM Jonathan Wakely wrote:
>
>
>
> On Sun, 16 Jan 2022 at 18:17, Patrick Palka via Libstdc++
> wrote:
>>
>> libstdc++-v3/ChangeLog:
>>
>> * testsuite/20_util/from_chars/double.cc: New test, consisting
>> of testcases extracted from the MSVC STL
On Mon, Jan 17, 2022 at 5:49 AM Jonathan Wakely wrote:
>
>
>
> On Sun, 16 Jan 2022 at 18:12, Patrick Palka via Libstdc++
> wrote:
>>
>> This makes fast_float handle the situation where std::from_chars is
>> specified to return result_out_of_range, i.e. when the parsed value
>> is outside the
We're going to use the fast_float library in our (compiled-in)
floating-point std::from_chars implementation for faster and more
portable parsing of binary32/64 decimal strings.
The single file fast_float.h is an amalgamation of the entire library,
which can be (re)generated with the command
This makes fast_float handle the situation where std::from_chars is
specified to return result_out_of_range, i.e. when the parsed value
is outside the representable range of the floating-point type.
This adjusts fast_float's behavior in case of over/underflow: instead of
returning errc{} and
This makes our std::from_chars implementation use fast_float for parsing
chars_format::scientific/fixed/general parsing into binary32/64 values.
For other floating-point formats we still use the fallback implementation
that goes through the strtod family of functions.
libstdc++-v3/ChangeLog:
This performs the following modifications to our local copy of fast_float
in order to make it more readily usable in our std::from_chars
implementation:
* Remove system #includes
* Replace stray call to assert
* Use the standard chars_format and from_chars_result types
Series tested on x86_64, i686, ppc64, ppc64le, aarch64, does it look OK for
trunk?
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc: Include .
(ascii_to_hexit, starts_with_ci): Define.
(__floating_from_chars_hex): Define.
(from_chars): Conditionally call
On Fri, 14 Jan 2022, Marek Polacek via Gcc-patches wrote:
> This is a "canonical types differ for identical types" ICE, which started
> with r11-4682. It's a bit tricky to explain. Consider:
>
> template struct S {
> S bar() noexcept(T::value); // #1
> S foo() noexcept(T::value);
libstdc++-v3/ChangeLog:
* testsuite/20_util/to_chars/103955.cc: Add explicit dg-do
directive.
---
libstdc++-v3/testsuite/20_util/to_chars/103955.cc | 1 +
1 file changed, 1 insertion(+)
diff --git a/libstdc++-v3/testsuite/20_util/to_chars/103955.cc
We currently crash when the floating-point to_chars overloads are passed
a precision value near INT_MAX, ultimately due to overflow in the bounds
checks that verify the output range is large enough.
The most portable fix seems to be to replace bounds checks of the form
A >= B + C (where B + C may
On Fri, 7 Jan 2022, Jakub Jelinek wrote:
> On Thu, Jan 06, 2022 at 10:44:09AM -0500, Patrick Palka via Gcc-patches wrote:
> > Fixed ever since r12-6188.
> >
> > PR c++/69681
> >
> > gcc/testsuite/ChangeLog:
> >
> > * g++.dg/cpp0x/constexpr
On Mon, 3 Jan 2022, 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 6/30/21
Fixed ever since r12-6188.
PR c++/69681
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-compare2.C: New test.
---
gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C | 10 ++
1 file changed, 10 insertions(+)
create mode 100644
Here we're rejecting the calls to g1 and g2 as ambiguous even though one
overload is more constrained than the other (and otherwise equivalent),
because the implicit 'this' parameter of the non-static overload causes
cand_parms_match to think the function parameter lists aren't equivalent.
This
r12-136 made us canonicalize an object/offset pair with negative offset
into one with a nonnegative offset, by iteratively absorbing the
innermost component into the offset and stopping as soon as the offset
becomes nonnegative.
This patch strengthens this transformation to make it keep absorbing
On Tue, Dec 28, 2021 at 10:08 AM Patrick Palka wrote:
>
> Here during satisfaction of B's associated constraints we're failing to
> reject the object-less call to the non-static member function A::size
> ultimately because satisfaction is performed in the (access) context of
> the class template
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 6/30/21 4:18 PM, Patrick Palka wrote:
> > > > > On Wed, Jun 30, 2021
Here during satisfaction of B's associated constraints we're failing to
reject the object-less call to the non-static member function A::size
ultimately because satisfaction is performed in the (access) context of
the class template B, which has a dependent bases, and so the
any_dependent_bases_p
In pointer_int_sum when called from a SFINAE context, we need to avoid
calling size_in_bytes_loc on an incomplete pointed-to type since this
latter function isn't SFINAE-friendly and always emits an error in this
case.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk
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 6/30/21 4:18 PM, Patrick Palka wrote:
> > > On Wed, Jun 30, 2021 at 3:51 PM Jason Merrill wrote:
> > >>
> > >> On 6/30/21 11:58 AM, Patrick Palka wrote:
> > >>> On Wed, 30
On Wed, Jun 30, 2021 at 4:23 PM Jason Merrill wrote:
>
> On 6/30/21 4:18 PM, Patrick Palka wrote:
> > On Wed, Jun 30, 2021 at 3:51 PM Jason Merrill wrote:
> >>
> >> On 6/30/21 11:58 AM, Patrick Palka wrote:
> >>> On Wed, 30 Jun 2021, Patrick Palka wrote:
> >>>
> On Fri, 25 Jun 2021, Jason
On Thu, 16 Dec 2021, Patrick Palka wrote:
> On Wed, 15 Dec 2021, Jason Merrill wrote:
>
> > On 12/15/21 12:49, Patrick Palka wrote:
> > > This patch makes us remember the function selected by overload
> > > resolution during ahead of time processing of a non-dependent call
> > > expression, so
On Wed, 15 Dec 2021, Jason Merrill wrote:
> On 12/15/21 12:49, Patrick Palka wrote:
> > This patch makes us remember the function selected by overload
> > resolution during ahead of time processing of a non-dependent call
> > expression, so that we avoid repeating most of the work of overload
> >
On Wed, 15 Dec 2021, Jason Merrill wrote:
> On 12/15/21 15:36, Patrick Palka wrote:
> > The r12-5403 fix apparently doesn't handle the case where the inner
> > lambda explicitly rather implicitly captures the capture proxy from
> > the outer lambda, and so we still reject the first example in the
On Wed, 15 Dec 2021, Jason Merrill wrote:
> On 12/10/21 09:53, Patrick Palka wrote:
> > In order to properly implement two-stage name lookup for dependent
> > operator expressions, we need to remember the result of unqualified
> > lookup of the operator at template definition time, and reuse
The r12-5403 fix apparently doesn't handle the case where the inner
lambda explicitly rather implicitly captures the capture proxy from
the outer lambda, and so we still reject the first example in the
testcase below.
The reason is that compared to an implicit capture, the effective
initializer
Tested on x86_64-pc-linux-gnu, does this look OK for trunk?
gcc/ChangeLog:
* print-tree.c (print_node) : Dump
DECL_LANG_FLAG_8.
---
gcc/print-tree.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/print-tree.c b/gcc/print-tree.c
index b5dc523fcb1..297492ad51c 100644
This patch makes us remember the function selected by overload
resolution during ahead of time processing of a non-dependent call
expression, so that we avoid repeating most of the work of overload
resolution at instantiation time. This mirrors what we already do for
non-dependent operator
On Wed, 15 Dec 2021, Jakub Jelinek wrote:
> On Mon, Dec 13, 2021 at 04:28:26PM -0500, Patrick Palka via Gcc-patches wrote:
> > * g++.dg/concepts/diagnostic18.C: Expect a "constraints on a
> > non-templated function" error.
> > * g++.dg/cpp23/auto-fncas
Here during constraint checking for the recursive call to 'f',
substitution into the PARM_DECL 'd' in the atomic constraint gives us
the wrong local specialization because local_specializations at this
point contains entities associated with the _outer_ call to 'f'.
This patch fixes this by
On Sun, 12 Dec 2021, Jason Merrill wrote:
> On 12/10/21 14:12, Patrick Palka wrote:
> > We use processing_template_decl in two slightly different ways: as
> > a flag to signal that we're dealing with templated trees, and its
> > magnitude is also used as a proxy for the current syntactic template
On Fri, Dec 10, 2021 at 3:57 PM Jeff Law wrote:
>
>
>
> On 12/10/2021 8:41 AM, Patrick Palka via Gcc-patches wrote:
> > The function comment for adjust_field_tree_exp says this special case
> > is for handling trees whose operands may contain pointers to RTL instead
&g
We use processing_template_decl in two slightly different ways: as
a flag to signal that we're dealing with templated trees, and its
magnitude is also used as a proxy for the current syntactic template
depth. This overloaded meaning of p_t_d is conceptually confusing and
leads to bugs that we end
'arglist' can be captured by a conversion within 'candidates', but if we
use a releasing_vec then we'll be sure to free it only after
'candidates' is freed by obstack_free.
Bootstrapped and regtested in x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* call.c
On Fri, Dec 10, 2021 at 10:48 AM Patrick Palka wrote:
>
> This flag is never set because non-dependent COMPOUND_EXPRs are fully
Whoops, this should say, ... non-dependent COMPOUND_EXPRs that resolve
to an overload are expressed as a CALL_EXPR at template definition
time ...
> resolved into a
This flag is never set because non-dependent COMPOUND_EXPRs are fully
resolved into a CALL_EXPR at template definition time (in
build_x_compound_expr) ever since r6-5772.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* cp-tree.h
The function comment for adjust_field_tree_exp says this special case
is for handling trees whose operands may contain pointers to RTL instead
of to trees. But ever since r0-59671, which fixed/removed the last two
tree codes for which this was possible (GOTO_SUBROUTINE_EXPR and
In order to properly implement two-stage name lookup for dependent
operator expressions, we need to remember the result of unqualified
lookup of the operator at template definition time, and reuse that
result rather than performing another unqualified lookup at
instantiation time.
Ideally we
On Wed, Dec 1, 2021 at 10:26 AM Marek Polacek via Gcc-patches
wrote:
>
> Here we ICE on
>
> int f() requires (auto(0));
>
> in do_auto_deduction when handling the auto: we're in a non-templated
> requires-expression which are parsed under processing_template_decl == 1
> and empty
601 - 700 of 1377 matches
Mail list logo
