In passing, use bool for its return type.
gcc/cp/ChangeLog:
* cp-tree.h (comp_template_args): Change return type to bool.
* pt.cc (comp_template_args): Document default arguments.
Change return type to bool and adjust returns accordingly.
---
gcc/cp/cp-tree.h | 2 +-
gcc/cp/ChangeLog:
* decl.cc (grokvardecl): Use current_template_constraints.
(xref_tag): Likewise.
* semantics.cc (finish_template_template_parm): Likewise.
---
gcc/cp/decl.cc | 13 +++--
gcc/cp/semantics.cc | 3 +--
2 files changed, 4 insertions(+), 12
This makes us avoid substituting into the TEMPLATE_PARM_CONSTRAINT of
each template parameter except as necessary for (friend) declaration
matching, like we already do for the overall TEMPLATE_PARMS_CONSTRAINTS
of a template parameter list.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does
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 BaseClass::baseDevice resolve to the second,
> > > > third and fourth
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 BaseClass::baseDevice resolve to the second,
> > > third and fourth overloads respectively in light of the cv-qualifiers
> > > of
On Thu, 26 May 2022, Patrick Palka wrote:
> Here we expect the calls to BaseClass::baseDevice resolve to the second,
> third and fourth overloads respectively in light of the cv-qualifiers
> of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the
> calls incorrectly resolve to the
Here we expect the calls to BaseClass::baseDevice resolve to the second,
third and fourth overloads respectively in light of the cv-qualifiers
of 'this' in each case. But ever since r12-6075-g2decd2cabe5a4f, the
calls incorrectly resolve to the first overload at instantiation time.
This happens
Here during cp_parser_single_declaration for #2, we were calling
associate_classtype_constraints for TPL (the primary template type)
before maybe_process_partial_specialization could get a chance to
notice that we're in fact declaring a distinct constrained partial
spec and not redeclaring the
On 5/18/22, Jason Merrill wrote:
> On 5/16/22 15:58, Patrick Palka wrote:
> > When processing a class template specialization, lookup_template_class
> > uses structural equality for the specialized type whenever one of its
> > template arguments uses structural equality. This the sensible thing
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:
> >>> On Fri, 6 May 2022, Patrick Palka wrote:
> >>>
> On Fri, 6 May 2022, Jason Merrill wrote:
>
>
When processing a class template specialization, lookup_template_class
uses structural equality for the specialized type whenever one of its
template arguments uses structural equality. This the sensible thing to
do in a vacuum, but given that we already effectively deduplicate class
On Thu, 12 May 2022, Jason Merrill wrote:
> On 5/12/22 14:14, Patrick Palka wrote:
> > On Thu, 12 May 2022, Patrick Palka wrote:
> >
> > > After r13-332-g88459c3965e2a2, it looks like we can safely remove the
> > > NULL test from TMPL_ARGS_HAVE_MULTIPLE_LEVELS, which simplifies its
> > >
On Thu, 12 May 2022, Patrick Palka wrote:
> After r13-332-g88459c3965e2a2, it looks like we can safely remove the
> NULL test from TMPL_ARGS_HAVE_MULTIPLE_LEVELS, which simplifies its
> semantics.
>
> And TMPL_ARGS_LEVEL should verify the level argument is sane in the
> one-dimensional vector
After r13-332-g88459c3965e2a2, it looks like we can safely remove the
NULL test from TMPL_ARGS_HAVE_MULTIPLE_LEVELS, which simplifies its
semantics.
And TMPL_ARGS_LEVEL should verify the level argument is sane in the
one-dimensional vector case. This change uncovered a couple of latent
bugs: in
This patch implements a simple tree wrapper, named tree_vec_range, which
lets us idiomatically iterate over all the elements of a TREE_VEC using
a C++11 range-based for loop:
// v is a TREE_VEC
for (tree e : tree_vec_range (v))
...
This is similar to the existing tree-based range
Tested on x86_64-pc-linux-gnu, does this look OK for the 10 branch?
NB: This backport of r12-1606 to the 10 branch deliberately omits parts
of P2325R3 so as to maximize backward compatibility with pre-P2325R3 code.
In particular, we don't remove the default ctors for back_insert_iterator,
Unlike in C, in C++ the conditional operator yields an lvalue if both
branches are lvalues, so we can just assign to PACK_EXPANSION_PATTERN
and ARGUMENT_PACK_ARGS directly.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* coroutines.cc
The accessor macros for TYPE_PACK_EXPANSION/EXPR_PACK_EXPANSION
and TYPE_ARGUMENT_PACK/NONTYPE_ARGUMENT_PACK should check the
tree code of the argument.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
* cp-tree.h (PACK_EXPANSION_CHECK):
On Fri, 6 May 2022, Jason Merrill wrote:
> On 5/6/22 16:10, Patrick Palka wrote:
> > On Fri, 6 May 2022, Patrick Palka wrote:
> >
> > > On Fri, 6 May 2022, Jason Merrill wrote:
> > >
> > > > On 5/6/22 14:00, Patrick Palka wrote:
> > > > > On Fri, 6 May 2022, Patrick Palka wrote:
> > > > >
> >
On Fri, 6 May 2022, Patrick Palka wrote:
> On Fri, 6 May 2022, Jason Merrill wrote:
>
> > On 5/6/22 14:00, Patrick Palka wrote:
> > > On Fri, 6 May 2022, Patrick Palka wrote:
> > >
> > > > On Fri, 6 May 2022, Jason Merrill wrote:
> > > >
> > > > > On 5/6/22 11:22, Patrick Palka wrote:
> > > >
On Fri, 6 May 2022, Jason Merrill wrote:
> On 5/6/22 14:00, Patrick Palka wrote:
> > On Fri, 6 May 2022, Patrick Palka wrote:
> >
> > > On Fri, 6 May 2022, Jason Merrill wrote:
> > >
> > > > On 5/6/22 11:22, Patrick Palka wrote:
> > > > > Here ever since r10-7313-gb599bf9d6d1e18,
> > > > >
On Fri, 6 May 2022, Patrick Palka wrote:
> On Fri, 6 May 2022, Jason Merrill wrote:
>
> > On 5/6/22 11:22, Patrick Palka wrote:
> > > Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p
> > > in C++11/14 is rejecting the marked sub-aggregate initializer (of type S)
> > >
> >
On Fri, 6 May 2022, Jason Merrill wrote:
> On 5/6/22 11:22, Patrick Palka wrote:
> > Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p
> > in C++11/14 is rejecting the marked sub-aggregate initializer (of type S)
> >
> >W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}}
> >
Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p
in C++11/14 is rejecting the marked sub-aggregate initializer (of type S)
W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}}
^
ultimately because said initializer has CONSTRUCTOR_NO_CLEARING set, and
so the
Here we're crashing from maybe_aggr_guide ultimately because
processing_template_decl isn't set when partially instantiating the
guide's parameter list. This causes us to prematurely force completion
of the dependent type Visitor_functior, which fails and results in
an unexpected error_mark_node.
Here, since finish_non_static_data_member isn't SFINAE friendly, we
incorrectly emit an error during overload resolution:
sfinae33.C: In substitution of ‘template A f() [with T = B]’:
sfinae33.C:11:7: required from here
sfinae33.C:5:31: error: invalid use of non-static data member ‘B::value’
Currently when checking the constraints of a class template, we do so in
the context of the template, not the specialized type. This is the best
we can do for a primary template since the specialized type is valid
only if the primary template's constraints are satisfied. But for a
partial
As in r12-6281-gc83ecfbe74a5cf for std::isdigit, shouldn't
use std::tolower either I think.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11 and the
12 branch after it's thawed?
PR libstdc++/103911
libstdc++-v3/ChangeLog:
* src/c++17/floating_from_chars.cc
The hexfloat parser for binary32/64 added in r12-6645-gcc3bf3404e4b1c
overlooked that the exponent part can also begin with an uppercase 'P'.
Tested on x86_64-pc-linux-gnu, does this look OK for trunk/11, and possibly the
12 branch now for 12.1?
PR libstdc++/105441
On Wed, Dec 15, 2021 at 5:10 PM Jason Merrill wrote:
>
> On 12/10/21 10:41, Patrick Palka 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
> > of to trees. But ever since r0-59671, which
Here ever since r12-6022-gbb2a7f80a98de3 we stopped deeming the partial
specialization #2 to be more specialized than #1 ultimately because
dependent operator expressions now have a DEPENDENT_OPERATOR_TYPE type
instead of an empty type, and this made unify stop deducing T(2) == 1
for K during
On Wed, 27 Apr 2022, Marek Polacek wrote:
> On Wed, Apr 27, 2022 at 11:00:46AM -0400, Patrick Palka wrote:
> > On Tue, 26 Apr 2022, Marek Polacek wrote:
> >
> > > Consider
> > >
> > > struct A {
> > > int x;
> > > int y = x;
> > > };
> > >
> > > struct B {
> > > int x = 0;
>
On Tue, 26 Apr 2022, Marek Polacek wrote:
> Consider
>
> struct A {
> int x;
> int y = x;
> };
>
> struct B {
> int x = 0;
> int y = A{x}.y; // #1
> };
>
> where for #1 we end up with
>
> {.x=(&)->x, .y=(&)->x}
>
> that is, two PLACEHOLDER_EXPRs for different types
On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote:
> We crash compiling this test since r11-7993 which changed
> lookup_template_class_1 so that we only call tsubst_enum when
>
> !uses_template_parms (current_nonlambda_scope ())
>
> But here current_nonlambda_scope () is the global
We need to pass tf_decltype when instantiating a non-dependent decltype
operand, like tsubst does in the dependent case, so that we avoid
materializing a temporary for a prvalue operand.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk/11?
PR c++/105386
On Mon, 25 Apr 2022, Jason Merrill wrote:
> On 4/22/22 15:27, Patrick Palka wrote:
> > On Fri, 22 Apr 2022, Patrick Palka wrote:
> >
> > > 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
On Fri, 22 Apr 2022, Patrick Palka wrote:
> 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
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)
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.
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
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
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
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
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
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, ...)
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:
> >
>
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
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
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.
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.
*
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
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
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:
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
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
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
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
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
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
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.
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
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.
---
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
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
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
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
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
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
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
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
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
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
>
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
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, 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:
> > > > >
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
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:
> > > > > >
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
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
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*
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 *)
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
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
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,
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
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, 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
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 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
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 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 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 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
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
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
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
Fixed by r12-7264.
PR c++/103443
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/consteval29.C: New test.
---
gcc/testsuite/g++.dg/cpp2a/consteval29.C | 20
1 file changed, 20 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval29.C
diff --git
We currently merge default template arguments for class templates, but
not for function templates. This patch fixes this by splitting out the
argument merging logic in redeclare_class_template into a separate
function and using it in duplicate_decls as well.
Bootstrapped and regtested on
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 least when it appears in a CTAD-enabled context.
This patch implements this using a new tsubst
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 an operation that
is never interesting to debug.
This patch addresses this problem in a
501 - 600 of 1377 matches
Mail list logo
