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, Jason Merrill wrote:
On 5/6/22 11:22, Patrick Palka wrote:
Here
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, reduced_constant_expression_p
in C++11/14 is rejecting the marked sub-aggregate initializer
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}}}
^
ultimately because said initializer has
On 5/5/22 16:57, Marek Polacek wrote:
On Wed, May 04, 2022 at 09:29:46PM -0400, Jason Merrill wrote:
On 5/4/22 19:20, Marek Polacek wrote:
On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote:
On 5/4/22 16:03, Marek Polacek wrote:
This patch fixes the second half of 64679. Here we
In my patch for PR100545 I added an assert to check for broken typedefs in
set_underlying_type, and it found one in this case:
rs6000_handle_altivec_attribute had the same problem as
handle_mode_attribute. So let's move the fixup into decl_attributes.
Tested that this fixes the ICE on a cross
On 5/4/22 19:20, Marek Polacek wrote:
On Wed, May 04, 2022 at 05:44:45PM -0400, Jason Merrill wrote:
On 5/4/22 16:03, Marek Polacek wrote:
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
In my previous PR104470 patch I added yet another place that needs to handle
dependent member rewriting for deduction guides; this patches centralizes
rewriting into maybe_dependent_member_ref. tsubst_baselink still has its
own handling because that's simpler than teaching
On 5/4/22 16:03, Marek Polacek wrote:
This patch fixes the second half of 64679. Here we issue a wrong
"redefinition of 'int x'" for the following:
struct Bar {
Bar(int, int, int);
};
int x = 1;
Bar bar(int(x), int(x), int{x}); // #1
cp_parser_parameter_declaration_list does
If the index of a constructor_elt is a FIELD_DECL, the CONSTRUCTOR is
already reshaped, so we can save time and memory by returning immediately.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* decl.cc (reshape_init): Shortcut already-reshaped init.
On 5/4/22 10:09, Patrick Palka wrote:
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
On 1/14/22 22:56, Jason Merrill wrote:
On 1/14/22 16:49, David Malcolm wrote:
On Mon, 2021-12-13 at 09:58 -0500, Jason Merrill via Gcc-patches wrote:
On 12/13/21 06:02, Jonathan Wakely wrote:
On Sun, 12 Dec 2021 at 05:39, Jason Merrill mailto:ja...@redhat.com>> wrote:
>
>
There's no reason to call cxx_printable_name_translate here instead of using
%D in the format string.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* error.c (cp_print_error_function): Use %qD.
(function_category): Use %qD.
---
gcc/cp/error.cc | 29
On 5/4/22 11:15, Marek Polacek wrote:
On Tue, May 03, 2022 at 04:46:11PM -0400, Jason Merrill wrote:
On 5/3/22 16:43, Jakub Jelinek wrote:
On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote:
On 5/2/22 12:19, Marek Polacek wrote:
This patch fixes an oversight whereby we treated >=
Jakub pointed out that cdtor_label is unnecessary, we should get all the
desired semantics with a normal return.
Tested x86_64-pc-linux-gnu and arm-eabi//arm-sim, applying to trunk.
gcc/cp/ChangeLog:
* cp-tree.h (struct language_function): Remove x_cdtor_label.
(cdtor_label,
On 4/27/22 16:30, 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;
int y = A{x}.y; // #1
};
where for #1 we end up
On 5/2/22 07:11, Jakub Jelinek wrote:
Hi!
On the following testcase, we emit deprecated warnings or unavailable errors
even on merge declarations of those lambdas (the dg-bogus directives), while
IMHO we should emit them only when something actually calls those lambdas.
The following patch
On 5/3/22 16:43, Jakub Jelinek wrote:
On Tue, May 03, 2022 at 04:26:51PM -0400, Jason Merrill wrote:
On 5/2/22 12:19, Marek Polacek wrote:
This patch fixes an oversight whereby we treated >= as the end of
a template argument. This causes problems in C++14, because in
On 5/2/22 12:18, Marek Polacek wrote:
Consider
struct F {
F(int) {}
F operator()(int) const { return *this; }
};
and
F(i)(0)(0);
where we're supposed to first call the constructor and then invoke
the operator() twice. However, we parse this as an init-declarator:
"(i)"
On 5/2/22 12:19, Marek Polacek wrote:
This patch fixes an oversight whereby we treated >= as the end of
a template argument. This causes problems in C++14, because in
cp_parser_template_argument we go different ways for C++14 and C++17:
/* It must be a non-type argument. In C++17 any
On 5/2/22 14:50, Patrick Palka wrote:
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
On 5/3/22 13:40, Patrick Palka wrote:
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
On PR102629 I noticed that we were giving the entire lambda as the location
for this template-id.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Copy location.
(do_auto_deduction): Use expr location.
While looking at PR96645 I noticed that while we were diagnosing names
changing meaning in the full class context, we weren't doing this for
lookups in nested class bodies.
Note that this breaks current range-v3; I've submitted a pull request to fix
its violation of the rule.
Tested
The the different calling of check_explicit_specialization for class and
namespace scope friends bothered me, so this patch combines them.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/91618
PR c++/96604
gcc/cp/ChangeLog:
* friend.cc (do_friend): Call
In this testcase, we were trying to substitute into
variant>::__accepted_type, but failed to look it up because
variant> doesn't exist. In other cases we already rewrite such
things into a dependent reference; we need to do that for alias templates as
well.
This caused some testsuite regressions
The stage 4 patch limited direct propagation of dependent type to capture
field/proxy to the "current instantiation", but many more types should be
suitable as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* lambda.cc (type_deducible_expression_p): Allow more
On 4/27/22 19:48, Jason Merrill wrote:
On 4/27/22 13:02, Joseph Myers wrote:
On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote:
+ if (typedef_variant_p (type))
+ {
+ /* Set up the typedef all over again. */
This seems wrong when the typedef is just being used in another
On 4/29/22 10:12, Marek Polacek wrote:
[dcl.dcl]/5 says that
enum { };
is ill-formed, and since r197742 we issue a pedwarn. However, the
pedwarn also fires for
enum { } x;
which is well-formed. So only warn when {} is followed by a ;. This
should be correct since you can't have
On 4/29/22 05:37, Richard Biener wrote:
This uses CASE_CONVERT more which eases eventual removal of NOP_EXPR.
Bootstrapped and tested on x86_64-unknown-linux-gnu, OK for trunk?
Jason, from the experiment this is from I know that the C++ FE
distinguishes between CONVERT_EXPR and NOP_EXPR at
Normally we check for incomplete type in start_decl, but that obviously
doesn't work for auto variables. Thanks to Pokechu22 for the analysis and
testcases:
"When cp_finish_decl calls cp_apply_type_quals_to_decl on a const auto or
constexpr auto variable, the type might not be complete the first
The decl pretty-printing code wasn't looking at the flags parameter, so we
were printing 'using' in the middle of an expression.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102987
gcc/cp/ChangeLog:
* error.cc (dump_decl) [USING_DECL]: Respect flags.
An alias can't be declared with a qualified-id in actual code, but in
diagnostics we want to know which scope it belongs to, and I think a
nested-name-specifier is the best way to provide that.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* error.cc (dump_decl):
My r161129 changed check_trait_type to reject arrays of unknown bound of
incomplete type, but I can't find a rationale for that, and now think it's
wrong: the standard just requires that the type be "complete, cv void, or an
array of unknown bound." I imagine that allowing arrays of unknown bound
PR49387 was a problem with initially asking for a typeid for a class
template specialization before it was complete, and later actually filling
in the descriptor when the class was complete, and thus disagreeing on the
form of the descriptor. I fixed that by forcing the class to be complete,
but
On 4/28/22 04:24, Iain Sandoe wrote:
Hi Jason,
On 20 Apr 2022, at 04:45, Jason Merrill wrote:
On 4/18/22 15:49, Eric Gallager via Gcc-patches wrote:
On Mon, Apr 18, 2022 at 10:01 AM Iain Sandoe via Gcc-patches
wrote:
From: Nathan Sidwell
This is a forward-port of a patch by Nathan
On 4/28/22 04:28, Iain Sandoe wrote:
Hi Jason,
On 20 Apr 2022, at 03:14, Jason Merrill wrote:
On 4/18/22 10:02, Iain Sandoe wrote:
There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral). The
intent
On 4/27/22 18:45, Marek Polacek wrote:
Here we wrongly reject the definition of "::N::a"
struct A;
namespace N { extern A a; }
struct A {} ::N::a;
because our code to diagnose a missing ; after a class definition doesn't
realize that :: can follow a class definition.
On 4/27/22 13:02, Joseph Myers wrote:
On Wed, 27 Apr 2022, Jason Merrill via Gcc-patches wrote:
+ if (typedef_variant_p (type))
+ {
+ /* Set up the typedef all over again. */
This seems wrong when the typedef is just being used in another
declaration with the mode
On 4/27/22 13:00, Marek Polacek wrote:
On Wed, Apr 27, 2022 at 11:47:02AM -0400, Jason Merrill wrote:
On 4/27/22 08:59, Marek Polacek wrote:
On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote:
On Tue, 26 Apr 2022, Marek Polacek via Gcc-patches wrote:
We crash compiling this test
On 4/27/22 08:59, Marek Polacek wrote:
On Wed, Apr 27, 2022 at 08:24:54AM -0400, Patrick Palka wrote:
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
The problem here was that handle_mode_attribute clobbered the changes of any
previous attribute, only copying type qualifiers to the new type. And
common_handle_aligned_attribute had previously set up the typedef, so when
we later called set_underlying_type it saw DECL_ORIGINAL_TYPE set and just
Here we were failing to diagnose that the initializer for the capture pack
is an unresolved overload. It turns out that the reason we didn't recognize
the deduction failure in do_auto_deduction was that the individual 'auto' in
the expansion of the capture pack was still marked as a parameter
On 4/26/22 09:45, Patrick Palka wrote:
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
Parameter packs from the enclosing context can be used unexpanded in a
lambda that is itself part of a pack expansion, but not packs that are part
of the lambda itself. We already check for capture packs; we also need to
check for function parameter packs of the lambda call operator.
Tested
On 4/25/22 14:10, Patrick Palka wrote:
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
On 4/22/22 14:36, Patrick Palka wrote:
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
On 4/22/22 19:57, Marek Polacek wrote:
Here we issue an error from c_build_shufflevector while parsing a template
because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs
(except the first two arguments). It checks if any of the arguments are
type-dependent, if so, we leave
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 testcases declare partial specializations for which the primary
Yes, also ok with that change.
On Thu, Apr 21, 2022, 10:22 AM Jakub Jelinek wrote:
> On Thu, Apr 21, 2022 at 09:20:48AM -0400, Marek Polacek via Gcc-patches
> wrote:
> > --- a/gcc/cp/constexpr.cc
> > +++ b/gcc/cp/constexpr.cc
> > @@ -4566,19 +4566,18 @@ cxx_eval_bit_cast (const constexpr_ctx
Ok.
On Thu, Apr 21, 2022, 9:20 AM Marek Polacek wrote:
> On Thu, Apr 21, 2022 at 08:56:23AM -0400, Jason Merrill wrote:
> > On 4/20/22 18:40, Marek Polacek wrote:
> > > Here we issue a bogus error for the first assert in the test. Therein
> > > we have
> > >
> > > = (void)
On 4/20/22 18:40, Marek Polacek wrote:
Here we issue a bogus error for the first assert in the test. Therein
we have
= (void) (VIEW_CONVERT_EXPR(yes) || handle_error ());,
VIEW_CONVERT_EXPR(value);
which has a COMPOUND_EXPR, so we get to cxx_eval_constant_expression
. The problem here is
On 4/18/22 18:09, Ed Catmur wrote:
If two arrays do not have the exact same element type including qualification, this could
be e.g. f(int (&&)[]) vs. f(int const (&)[]), which can still be distinguished
by the lvalue-rvalue tiebreaker.
By tightening this branch (in accordance with the letter
On 4/18/22 15:49, Eric Gallager via Gcc-patches wrote:
On Mon, Apr 18, 2022 at 10:01 AM Iain Sandoe via Gcc-patches
wrote:
From: Nathan Sidwell
This is a forward-port of a patch by Nathan (against 10.x) which fixes an open
PR.
We are ICEing because we ended up tsubst_copying something that
On 4/18/22 11:34, Iain Sandoe wrote:
We check that the final_suspend () method returns a sane type (i.e. a class
or structure) but, unfortunately, that check has to be later than the one
for a throwing case. If the user returns some nonsensical type from the
method, we need to handle that in
On 4/18/22 10:03, Iain Sandoe wrote:
Whether it was intended or not, it is possible to define a coroutine promise
with multiple return_value() methods [which need not even have the same type].
We were not accounting for this possibility in the check to see whether both
return_value and
On 4/18/22 10:02, Iain Sandoe wrote:
There are a few cases where we can generate a temporary that does not need
to be added to the coroutine frame (i.e. these are genuinely ephemeral). The
intent was that unnamed temporaries should not be 'promoted' to coroutine
frame entries. However there
On Tue, Apr 19, 2022, 6:53 AM Jakub Jelinek wrote:
> On Mon, Apr 18, 2022 at 09:57:12AM -0400, Patrick Palka wrote:
> > > Hmm, Patrick made a similar change and then reverted it for PR90996.
> > > But it makes sense to me; when we replace placeholders, it's
> appropriate
> > > to look at the
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, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or
On 4/13/22 19:17, Marek Polacek wrote:
On Tue, Apr 12, 2022 at 04:01:14PM -0400, Jason Merrill wrote:
On 4/12/22 14:38, Marek Polacek wrote:
On Mon, Apr 11, 2022 at 04:39:22PM -0400, Jason Merrill wrote:
On 4/8/22 15:21, Marek Polacek wrote:
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason
On 4/14/22 16:24, Marek Polacek wrote:
Here we issue a wrong error for the
template>> void g();
line in the testcase. I surmise that's because we mistakenly parse
C_many as a placeholder-type-specifier, and things go wrong from
there. We are in a default argument so we should reject
There's been an extension for a long time to allow applying 'unsigned' to an
int typedef, but that was confusing the integer promotion code. Fixed by
forgetting about the typedef in that case.
I'm going to make this an unconditional pedwarn in stage 1.
Tested x86_64-pc-linux-gnu, applying to
The expression pretty-printing code crashed on a location wrapper with no
type, and didn't know what to do with a USING_DECL.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102987
gcc/cp/ChangeLog:
* error.cc (dump_expr): Handle USING_DECL.
[VIEW_CONVERT_EXPR]:
The constexpr constructor checking code got confused by the expansion of a
trivial copy constructor; we don't need to do that checking for defaulted
ctors, anyway.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104646
gcc/cp/ChangeLog:
* constexpr.cc
When a captured variable is type-dependent, we've expressed the type of the
capture field and proxy with a decltype variant. But if the type is "the
current instantiation", we need to be able to see that so that we can do
lookup inside it just like we could with the captured variable itself.
I
Because common_handle_aligned_attribute only applies the alignment to the
TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it
explicitly in tsubst.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/65211
gcc/cp/ChangeLog:
* pt.cc (tsubst_decl)
When instantiating the op() for a generic lambda, we can no longer do name
lookup inside function scopes enclosing the lambda, so we need to remember
the lookup result from processing the definition of the lambda. So the code
in finish_call_expr to throw away the lookup result and instead look it
Asking for conversion to a dependent type also makes a BASELINK dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101698
gcc/cp/ChangeLog:
* pt.cc (tsubst_baselink): Also check dependent optype.
gcc/testsuite/ChangeLog:
* g++.dg/template/conv19.C: New
This issue goes back to r83221, where the cleanup for extended ref temps
changed from being unconditional to being tied to the declaration they
formed part of the initializer for.
The named return value optimization changes the cleanup for the NRV variable
to only run on the EH path; we don't
The patch for 100111 extended our handling of empty base elision to the case
where the derived class has no other fields, but we still need to make sure
that there's some initializer for the derived object.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105245
PR
On 4/13/22 04:11, Jakub Jelinek wrote:
Hi!
The following testcase fails, because we only constant evaluate the
alignas argument as non-manifestly constant-evaluated and as
__builtin_is_constant_evaluated appears, we make it non-constant
(the reason is that we often try to evaluate some
On 4/12/22 18:50, Marek Polacek wrote:
DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence). That means that reference-related is
now more broad, which means that we will be
There were two problems with this testcase: we weren't copying the target
attribute from the second declaration to the global alias for the first
one (duplicate_decls hunk), and then we were treating the third one as
matching the earlier one even though both are versioned (decls_match hunk).
The
While considering the PR102071 patch for backporting, I noticed that I was
considering the alignment of the array new cookie even when there isn't one
because we aren't allocating an array.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102071
gcc/cp/ChangeLog:
* init.cc
On 4/12/22 15:48, Patrick Palka wrote:
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
On 4/12/22 14:44, 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
On 4/12/22 14:38, Marek Polacek wrote:
On Mon, Apr 11, 2022 at 04:39:22PM -0400, Jason Merrill wrote:
On 4/8/22 15:21, Marek Polacek wrote:
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote:
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype,
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 contains an
ARGUMENT_PACK_SELECT (which just resolves to the parameter
On 3/24/22 17:06, Jason Merrill wrote:
On 3/22/22 16:59, Marek Polacek via Gcc-patches wrote:
On Tue, Mar 22, 2022 at 08:39:21PM +, Ed Catmur wrote:
If two arrays do not have the exact same element type including
qualification, this could be e.g. f(int (&&)[]) vs. f(int const
(&)[]),
Trivial initialization shouldn't bump a variable out of .rodata; if the
result of build_aggr_init is an empty STATEMENT_LIST, throw it away.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104142
gcc/cp/ChangeLog:
* decl.cc (check_initializer): Check TREE_SIDE_EFFECTS.
In a template class A we normally add an implicit using A::operator= as a
placeholder for the implicitly declared operator whose signature we don't
know yet. In my patch for PR92918 I stopped doing that if the class has an
explicit operator=, but that was wrong; an operator= taking an unrelated
The standard says, as we quote in the comment just above, that if we don't
find operator new in the allocated type, it should be looked up in the
global scope. This is specifically ::, not just any namespace, and we
already give an error for an operator new declared in any other namespace.
On 4/8/22 15:21, Marek Polacek wrote:
On Wed, Apr 06, 2022 at 04:55:54PM -0400, Jason Merrill wrote:
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list.
On 4/7/22 18:25, Alexandre Oliva wrote:
Hello, Jason,
On Apr 6, 2022, Jason Merrill wrote:
On 4/6/22 15:36, Alexandre Oliva wrote:
Please adjust your patch subject lines for the new guidelines adopted
as part of the git transition:
https://gcc.gnu.org/contribute.html#patches
Oh, wow, I
On 4/7/22 18:48, Alexandre Oliva wrote:
On Apr 6, 2022, Jason Merrill wrote:
On 4/6/22 15:37, Alexandre Oliva wrote:
Need to adjust this subject line, as well.
*nod*, thanks
* tree.cc (protected_set_expr_location): Propagate locus to
call wrapped in cast-to-void.
I'm reluctant to put
My patch for PR92385 made us use VEC_INIT_EXPR for aggregate initialization
of an array where some elements are not explicitly initialized. Constexpr
handling of that was treating initialization from {} as equivalent to
value-initialization, which is problematic for classes with default member
This rule that for a friend with a qualified name we try to find a
matching template was already in C++98, but it seems we never implemented
it, and nobody reported it until 2019.
This patch sets DECL_IMPLICIT_INSTANTIATION to signal to
check_explicit_specialization that we want to find a
We've had a diagnostic for this, but since r10-6571 added an assert to
splice_late_return_type, we need to diagnose before we call it.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101051
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Reject conversion with trailing
We were already checking COMPLETE_TYPE_P to recognize instantiation of a
generic lambda, but didn't consider that we might be nested in a non-generic
lambda.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101717
gcc/cp/ChangeLog:
* lambda.cc (lambda_expr_this_capture):
My cleanup in r12-296 cleared TREE_HAS_CONSTRUCTOR on digested class
initializers, but we leave it set for vectors, since we can't wrap them in
TARGET_EXPR.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/105187
gcc/cp/ChangeLog:
* typeck2.cc (store_init_value): Allow
On 4/6/22 15:45, Marek Polacek via Gcc-patches wrote:
On Wed, Apr 06, 2022 at 04:36:49PM -0300, Alexandre Oliva via Gcc-patches wrote:
On targets that return this from cdtors, cxx_eval_call_expression may
flag flowing off the end of a dtor. That's preempted for ctors, and
avoided entirely
On 4/6/22 15:37, Alexandre Oliva wrote:
Need to adjust this subject line, as well.
This patch fixes a divergence in line numbers in diagnostics and,
presumably, debug information, between targets whose cdtors return
this and those that don't.
The problem was visible in
On 4/6/22 15:36, Alexandre Oliva wrote:
Please adjust your patch subject lines for the new guidelines adopted as
part of the git transition:
https://gcc.gnu.org/contribute.html#patches
e.g. [PATCH] c++: tolerate cdtors returning this in constexpr [PRn]
On targets that return this from
On 4/1/22 15:14, Marek Polacek wrote:
Attribute format takes three arguments: archetype, string-index, and
first-to-check. The last two specify the position in the function
parameter list. r63030 clarified that "Since non-static C++ methods have
an implicit this argument, the arguments of such
On 4/6/22 11:26, Jakub Jelinek wrote:
On Wed, Apr 06, 2022 at 11:18:32AM -0400, Jason Merrill wrote:
Why not check at the beginning of the function?
You just pinged this patch, but I haven't seen a response to this question.
I thought the
Here, because of problems with the new warning-control code and expressions
that change location, the suppress_warning on the INDIRECT_REF didn't work.
Those problems still need to be worked out, but it's simple to avoid needing
to use suppress_warning in the first place by using a reference
On 4/6/22 11:11, Patrick Palka wrote:
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
On 3/25/22 14:08, Jason Merrill wrote:
On 3/25/22 12:34, Jakub Jelinek wrote:
Hi!
cplus_decl_attributes can be called with attributes equal to
error_mark_node, there are some spots in the function that test
it or decl_attributes it calls starts with:
if (TREE_TYPE (*node) == error_mark_node
On 4/6/22 10:41, Jakub Jelinek wrote:
On Fri, Feb 11, 2022 at 07:55:50PM +0100, Jakub Jelinek via Gcc-patches wrote:
Something like the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c16
will still be needed with adjusted testcase from
The patch for PR92024 changed -Wshadow=compatible-local to warn if either
new or old decl was a type, but the rationale only talked about the case
where both are types. If only one is, they aren't compatible.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/100608
This bug was an object/value confusion; we are interested in the size
of *b.ip, but instead the code was calculating the size of b.ip itself.
This seems to be because compute_objsize will compute the size of whatever
object it can find in the argument: if you pass it a VAR_DECL, it gives you
the
1001 - 1100 of 2962 matches
Mail list logo
