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 parsin
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 Mer
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 s
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 whol
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 was
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 return_vo
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 the
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 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/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 th
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) (VIEW_CONVERT_EXPR(y
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 *ct
On 1/18/22 05:10, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled. We see the constructor is immediate,
in build_over_call we trigger:
if (obj_arg && is_dummy_object (obj_arg))
{
call = build_cplus_new (DECL_CONTEXT (fndecl), call, complain)
On 1/18/22 05:17, Jakub Jelinek wrote:
On Thu, Jan 13, 2022 at 04:18:33PM -0500, Jason Merrill wrote:
Note, address_compare has some special cases, e.g. it assumes that
static vars are never adjacent to automatic vars, which is the case
for the usual layout where automatic vars are on the stack
On 1/18/22 09:26, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 09:08:03AM -0500, Jason Merrill wrote:
which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP,
but then call cxx_constant_value on it. In cxx_eval_outermost_constant_expr
it triggers the:
else if (TREE_CODE (t)
On 1/18/22 11:40, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 11:25:38AM -0500, Jason Merrill wrote:
Can you please comment on https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86369#c1
then?
Done.
Thanks.
About the rest of the patch, I thought I had seen richi comment on IRC (but
can't find t
For this testcase, the cleanup that is supposed to happen if initialization
throws was wrongly being run on the normal control path as well. This turns
out to be because the EH-only handling in gimple_push_cleanup didn't apply
to conditional cleanups such as we have for nothrow new, since we check
On 1/18/22 11:08, Patrick Palka wrote:
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
On 1/18/22 13:06, Martin Sebor wrote:
On 1/18/22 06:37, Richard Sandiford wrote:
In this PR the waccess pass was fed:
D.10779 ={v} {CLOBBER};
VIEW_CONVERT_EXPR(D.10779) = .MASK_LOAD_LANES
(addr_5(D), 64B, _2);
_7 = D.10779.__val[0];
However, the tracking of m_clobbers only looked at
Debug information was getting confused because input_location was different
depending on whether we had looked ahead to see if the next tokens look like
a template argument list.
I tried resetting input_location in cp_lexer_rollback_tokens itself, but
that caused regressions, so let's just do it h
On 1/18/22 18:07, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 11:51:31AM -0500, Jason Merrill wrote:
On 1/18/22 09:26, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 09:08:03AM -0500, Jason Merrill wrote:
which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP,
but then call cxx_con
On 1/18/22 18:20, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 05:56:47PM -0500, Jason Merrill wrote:
Debug information was getting confused because input_location was different
depending on whether we had looked ahead to see if the next tokens look like
a template argument list.
I tried resett
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.f)(args) but we're
trying to evaluate it using the intermediate CAL
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 Jason Merrill wrote:
On 6/30/21 4:18 PM, Patrick Palka wrote:
On Wed, Jun 30, 2021
On 1/19/22 17:32, Patrick Palka wrote:
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 Ja
The patch for PR41723 properly changed one place to look into the current
instantiation; now we need to fix this place as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/102300
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_name): Use dependent_scope_p.
gcc/tests
On 1/18/22 11:05, Marek Polacek wrote:
On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote:
On 1/14/22 19:22, Marek Polacek 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
A C++20 designator must name a direct non-static member of the class; in
this case it names a member of a base class, and we should give an error
instead of crashing.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/101405
gcc/cp/ChangeLog:
* decl.cc (reshape_init_class): R
On 1/20/22 20:03, Marek Polacek wrote:
On Thu, Jan 20, 2022 at 03:23:24PM -0500, Jason Merrill wrote:
On 1/18/22 11:05, Marek Polacek wrote:
On Mon, Jan 17, 2022 at 01:48:48PM -0500, Jason Merrill wrote:
On 1/14/22 19:22, Marek Polacek wrote:
This is a "canonical types differ for identical ty
Fixing a thinko in my patch for 103681: when computing the size of a virtual
base, it would help to use its binfo instead of the one for the derived
class.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104139
PR c++/103681
gcc/cp/ChangeLog:
* class.cc (end_of_cla
On 1/21/22 12:42, Marek Polacek wrote:
On Fri, Jan 21, 2022 at 09:27:17AM -0500, Jason Merrill wrote:
On 1/20/22 20:03, Marek Polacek wrote:
@@ -2815,12 +2816,23 @@ fixup_deferred_exception_variants (tree type, tree
raises)
cp_cv_quals var_quals = TYPE_QUALS (variant);
My patch for PR20040 made us stop exiting early from build_new_1 in
cases of trivial initialization if there's a class operator delete; as a
result, code later in the function needs to handle this case properly.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104084
PR c++/2
While looking at another bug I wanted the compiler to tell me what the two
unequal values were.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* semantics.cc (find_failing_clause): Return expr if not
decomposable.
(finish_static_assert): Show constant va
We've been trying for a while to avoid TARGET_EXPRs in template code, but
there were still a few that snuck through, and the one in this case broke
the code that tried to handle it. Fixed by using IMPLICIT_CONV_EXPR, as we
have done elsewhere.
I also noticed that finish_compound_literal was assum
This is the same issue as PR104031, but that patch doesn't fix this
testcase because in this case, current_function_decl isn't set when we get
to cp_genericize_target_expr. But there seems to be no need for
is_local_temp to check for function scope; !TREE_STATIC should be enough.
Tested x86_64-pc
On 1/17/22 14:29, will wray wrote:
Attached
(the cut n paste looks like it removed some whitespace formatting)
Pushed, thanks! I incorporated the introduction from your initial email
in the commit message.
Jason
On 1/22/22 16:24, Patrick Palka wrote:
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 COMPOU
On 1/24/22 10:27, Patrick Palka wrote:
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
t
On 1/25/22 06:02, Jakub Jelinek wrote:
On Mon, Jan 24, 2022 at 11:26:27PM +0100, Jakub Jelinek via Gcc-patches wrote:
Yet another short term solution might be not use DW_TAG_base_type
for the IEEE quad long double, but instead pretend it is a DW_TAG_typedef
with DW_AT_name "long double" to __flo
On 1/25/22 12:33, Patrick Palka wrote:
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 fai
Given build_this of a TARGET_EXPR, cp_build_fold_indirect_ref returns the
TARGET_EXPR. But that's the wrong value category for the result of the
defaulted class assignment operator, which returns an lvalue, so we need to
actually build the INDIRECT_REF.
Tested x86_64-pc-linux-gnu, applying to tru
Usually we handle DR1558 substitution near the top of tsubst, but in this
case while substituting TYPENAME_TYPE we were passing an alias
specialization to tsubst_aggr_type, which ignored its aliasness.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/103057
gcc/cp/ChangeLog:
On 1/26/22 04:33, Jakub Jelinek wrote:
Hi!
The middle-end uses sometimes VECTOR_TYPE CONSTRUCTORs that contain
some other VECTOR_TYPE elements in it (should be with compatible element
size and smaller number of elements, e.g. a V8SImode vector can be
constructed as { V4SImode_var_1, V4SImode_var
On 1/25/22 18:33, Marek Polacek wrote:
Here, -Wuse-after-free warns about using 'this' which, on ARM, cdtors
return, as mandated by the EABI. To be entirely correct, it only
requires it for C1 and C2 ctors and D2 and D1 dtors, but I don't feel
like changing that now and possibly running into iss
cp_parser_template_id wasn't prepared to handle getting a USING_DECL back
from cp_parser_template_name. Let's defer that case to instantiation time,
as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104235
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_name): Re
My patch for PR101072 removed the specific VECTOR_TYPE handling here, which
broke pr72747-2.c on PPC; this patch restores it.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104206
PR c++/101072
gcc/cp/ChangeLog:
* semantics.cc (finish_compound_literal): Restore VE
The problem with this testcase was that since my patch for PR97900 we
weren't preserving DECL_UID identity for parameters of instantiations of
templated functions, so using those parameters as the keys for the
defarg_inst map broke. I think this was always fragile given the
possibility of redeclar
On 1/26/22 18:55, Marek Polacek wrote:
In r12-1933 I attempted to implement DR2397 aka allowing
int a[3];
auto (&r)[3] = a;
by removing the type_uses_auto check in create_array_type_for_decl.
That may have gone too far, because it also allows arrays of
CLASS_PLACEHOLDER_TEMPLATE and it lo
On 1/27/22 09:02, Patrick Palka wrote:
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
On 1/26/22 12:49, Patrick Palka wrote:
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
A flaw in my patch for PR51344 was that cplus_decl_attributes calls
decl_attributes after save_template_attributes, which messes up the ordering
that save_template_attributes set up. Fixed by splitting
save_template_attributes around the call to decl_attributes.
Tested x86_64-pc-linux-gnu, applyi
On 1/27/22 13:06, Patrick Palka wrote:
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
On 1/27/22 20:02, Marek Polacek wrote:
Here we ICE in unify_array_domain when we're trying to deduce the type
of an array, as in
auto(*p)[i] = (int(*)[i])0;
but unify_array_domain doesn't arbitrarily complex bounds. Another
test is, e.g.,
auto (*b)[0/0] = &a;
where the type of the arra
The GCC 8 lambda overhaul fixed most uses of lambdas in pack expansions, but
local enums and classes within such lambdas that depend on parameter packs
are still broken. For now, give a sorry instead of an ICE or incorrect
error.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/1001
On 1/28/22 12:54, Patrick Palka wrote:
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
On 1/31/22 12:27, Patrick Palka wrote:
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
On 1/28/22 15:49, Marek Polacek wrote:
On Thu, Jan 27, 2022 at 10:17:00PM -0500, Jason Merrill wrote:
On 1/27/22 20:02, Marek Polacek wrote:
@@ -11159,8 +11159,16 @@ create_array_type_for_decl (tree name, tree type, tree
size, location_t loc)
/* Figure out the index type for the array. *
On 1/28/22 20:21, Marek Polacek wrote:
Weird things are going to happen if you define your std::initializer_list
as a union. In this case, we crash in output_constructor_regular_field.
Let's not allow such a definition in the first place.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for t
On 1/31/22 11:14, Patrick Palka wrote:
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 wha
Ping.
On 1/26/22 18:16, Jason Merrill wrote:
The problem with this testcase was that since my patch for PR97900 we
weren't preserving DECL_UID identity for parameters of instantiations of
templated functions, so using those parameters as the keys for the
defarg_inst map broke. I think this was
On 1/31/22 14:03, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, in some cases we preprocess incorrectly when we
encounter an identifier which is defined as function-like macro, followed
by at least 2 CPP_PADDING tokens and then some other identifier.
On the following testcase, the problem is
On 2/1/22 10:31, Jakub Jelinek wrote:
On Tue, Feb 01, 2022 at 10:03:57AM +0100, Jakub Jelinek via Gcc-patches wrote:
I wonder if we shouldn't replace that
toks[0] = pfile->directive_result;
line with
toks[0] = pfile->avoid_paste;
or even replace those
toks = XNEW (cpp_token)
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 handle ARGUMENT_PACK_SELECT in
iterative_hash_template_arg
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 the enclosing scope, which aren't a part of the lambda's
DECL_TI_ARGS
The patch for PR55227 changed the minimal init-list handling in
cp_complete_array_type to a call to reshape_init, which broke on the dependent
initializer. It occurred to me that trying to deduce the array size from a
dependent init-list is wrong in general, as we can see with the second
testcase,
On 2/3/22 05:27, Richard Biener wrote:
The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after
variable creation since NRV runs _after_ the function was inlined and thus
affects the inlined variables copy indirectly. We may adjust the abstract
origin of a variable only at the point we
On 1/20/22 17:54, Martin Sebor wrote:
The updated patch ensures the tighter bound isn't used to compute
the sprintf result and adds a test to verify that. (This is messy
in the strlen/sprintf pass and should be cleaned up to avoid this
mistake in the future.)
Rested on x86_64-linux.
OK, thank
On 2/3/22 10:52, Jakub Jelinek wrote:
On Tue, Jan 18, 2022 at 05:40:48PM +0100, Jakub Jelinek via Gcc-patches wrote:
About the rest of the patch, I thought I had seen richi comment on IRC (but
can't find the comment now) that these cases where we could give a constant
answer but decide not to be
On 2/3/22 11:49, Patrick Palka wrote:
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, cau
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 iterative_hash_template_arg and
template_args_equal, which would otherwise cr
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 noexcept-spec
afterwards, it should have been set by ~com
On 2/3/22 15:33, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 03:07:03PM -0500, Jason Merrill wrote:
--- gcc/fold-const.h.jj 2022-02-01 20:10:51.235856007 +0100
+++ gcc/fold-const.h2022-02-03 15:02:02.700228631 +0100
-/* Non-zero if we are folding constants inside an initializer; zero
- ot
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 satisfaction cache needs to look through ARGUMENT_PACK_SELECT
template argument
On 2/3/22 16:18, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote:
I think it would be clearer to leave the !DECL_P case alone and add
/* In C++ it is unspecified, and so non-constant, whether two
equivalent strings have the same address. */
else if (fold
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 instantiate the
noexcept-spec afterwards.
Hmm, there shouldn't be any
On 2/4/22 08:41, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:34:17PM -0500, Jason Merrill wrote:
On 2/3/22 16:18, Jakub Jelinek wrote:
On Thu, Feb 03, 2022 at 04:04:57PM -0500, Jason Merrill wrote:
I think it would be clearer to leave the !DECL_P case alone and add
/* In C++ it is unspeci
On 2/4/22 09:12, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, for C++98 we have diagnostics that expect
terminating template arguments to be a mistake for > > (C++11
said it has to be treated that way), while if user trying to spare the
spacebar doesn't separate > from following = or >> fr
On 2/4/22 12:04, Patrick Palka wrote:
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 forg
On 2/4/22 17:10, Jakub Jelinek wrote:
On Fri, Feb 04, 2022 at 04:54:39PM -0500, Jason Merrill wrote:
Bootstrapped/regtested on powerpc64le-linux, ok for trunk?
Or shall it wait for GCC 13?
Hmm, I lean toward GCC 13; this seems more of a stage 3 change.
Ok.
I see you test valid uses of >= i
The PR92385 fix meant that we see more VEC_INIT_EXPR outside of INIT_EXPR;
in such cases, we need to wrap them in TARGET_EXPR. I previously fixed
that in build_array_copy; we also need it in process_init_constructor.
After fixing that, I needed to adjust a few places to recognize the
VEC_INIT_EXPR
On 2/5/22 07:17, Jakub Jelinek wrote:
On Sat, Feb 05, 2022 at 12:02:14AM +0100, Jakub Jelinek via Gcc-patches wrote:
You mean for folding_cxx_constexpr ? The code does that basically, with one
exception, the folding_initializer FUNCTION_DECL cmp FUNCTION_DECL case.
We don't track sizes of funct
On 2/7/22 12:34, Patrick Palka wrote:
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:
T
On 2/7/22 09:57, 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 w
On 2/7/22 09:57, Patrick Palka wrote:
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.
On 2/8/22 03:16, Jakub Jelinek wrote:
Hi!
I've added the assert because start_decl diagnoses such vars for C++20 and
earlier:
if (current_function_decl && VAR_P (decl)
&& DECL_DECLARED_CONSTEXPR_P (current_function_decl)
&& cxx_dialect < cxx23)
but as can be seen, we cam trigger
On 2/8/22 03:22, Jakub Jelinek wrote:
Hi!
The following patch suppresses extraneous -Wshadow warnings.
On the testcase without the patch we emit 14 -Wshadow warnings,
with the patch just 4. It is enough to warn once e.g. during parsing of the
template or the abstract ctor, while previously we'd
On 2/8/22 03:35, Richard Biener wrote:
On Tue, 8 Feb 2022, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, since PR96690 r11-2834 we call rtl_for_decl_init
which can call expand_expr already during early_dwarf. The comment and PR
explains it that the intent is to ensure the referenced vars a
On 2/8/22 15:11, Qing Zhao wrote:
Hi,
This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at
cp/cxx-pretty-print.c:128)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515
It's possible that the TYPE_NAME of a record_type is NULL, therefore when
printing the TYPE_NAME, we should
On 2/8/22 16:59, Martin Sebor wrote:
Transforming a by-value arguments to by-reference as GCC does for some
class types can trigger -Wdangling-pointer when the argument is used
to store the address of a local variable. Since the stored value is
not accessible in the caller the warning is a false
This is a case missed by my recent fixes to aggregate initialization and
exception cleanup for PR94041 et al: we also need to clean up members with
constant initialization if initialization of a later member throws.
It also occurs to me that we needn't bother building the cleanups if
-fno-exceptio
The C++ committee just updated the values of these macros to reflect some
late C++20 papers that we implement but others don't yet; see PR103891.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/c-family/ChangeLog:
* c-cppbuiltin.cc (c_cpp_builtins): Update values
of __cpp_cons
On 2/9/22 03:30, Richard Biener wrote:
On Tue, Feb 8, 2022 at 11:38 PM Jason Merrill via Gcc-patches
wrote:
On 2/8/22 16:59, Martin Sebor wrote:
Transforming a by-value arguments to by-reference as GCC does for some
class types can trigger -Wdangling-pointer when the argument is used
to
We weren't streaming a C++20 dependent explicit-specifier.
gcc/cp/ChangeLog:
* module.cc (trees_out::core_vals): Stream explicit specifier.
(trees_in::core_vals): Likewise.
* pt.cc (store_explicit_specifier): No longer static.
(tsubst_function_decl): Clear DECL_HAS
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 pruned the
overload set for the non-dependent call ahead
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 non-dependent using-decl. This caused
us to crash in the below testca
On 2/9/22 10:51, Qing Zhao wrote:
On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote:
On 2/8/22 15:11, Qing Zhao wrote:
Hi,
This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at
cp/cxx-pretty-print.c:128)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101515
It's possible that th
On 2/9/22 16:01, Qing Zhao wrote:
On Feb 9, 2022, at 12:23 PM, Jason Merrill wrote:
On 2/9/22 10:51, Qing Zhao wrote:
On Feb 8, 2022, at 4:20 PM, Jason Merrill wrote:
On 2/8/22 15:11, Qing Zhao wrote:
Hi,
This is the patch to fix PR101515 (ICE in pp_cxx_unqualified_id, at
cp/cxx-pretty
On 2/9/22 15:15, Patrick Palka wrote:
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 intro
On 2/9/22 21:18, Zhao Wei Liew via Gcc-patches wrote:
Hi!
I wrote a patch for PR 25689, but I feel like it may not be the ideal
fix. Furthermore, there are some standing issues with the patch for
which I would like tips on how to fix them.
Specifically, there are 2 issues:
1. GCC warns about if
This test regressed after my PR103752 patch with -march=cascadelake. I
don't understand why that flag makes a difference, but this patch is correct
in any case.
Tested x86_64-pc-linux-gnu, applying to trunk.
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_specializations): Use
801 - 900 of 2965 matches
Mail list logo
