Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
I noticed that we were ignoring all the special rules for when to use a
simple INIT_EXPR for array initialization from a CONSTRUCTOR, because
split_nonconstant_init_1 was also passing 1 to the from_array parameter.
Arguably that's the real b
On 10/2/22 07:35, Jakub Jelinek wrote:
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote:
--- gcc/cp/decl.cc.jj 2022-09-22 00:14:55.478599363 +0200
+++ gcc/cp/decl.cc 2022-09-22 00:24:01.121178256 +0200
@@ -223,6 +223,7 @@ struct GTY((for_user)) named_label_entry
bool in_
On 10/3/22 08:48, Patrick Palka wrote:
On Fri, 30 Sep 2022, Jason Merrill wrote:
On 9/30/22 11:14, Patrick Palka wrote:
On Thu, 29 Sep 2022, Jason Merrill wrote:
On 9/29/22 11:05, Patrick Palka wrote:
Adding a new builtin trait currently involves some boilerplate (as can
be seen in r13-2956
On 9/30/22 18:50, Iain Sandoe wrote:
Hi Jason,
On 30 Sep 2022, at 23:06, Jason Merrill wrote:
You can't use CONVERT_EXPR to convert between two class types, and it was
breaking copy elision.
Unfortunately, this patch breaks symmetric-transfer-00-basic.C, where
susp_type is Loopy::handle_type
On 10/3/22 20:42, Patrick Palka wrote:
This is apparently needed since we include cp-trait.def from cp-tree.h
(in order to define the cp_trait_kind enum), as with operators.def.
Tested on x86_64-pc-linux-gnu by doing make install and verifying
cp-trait.def appears in
$prefix/lib/gcc/x86_64-p
On 10/3/22 15:22, Jakub Jelinek wrote:
On Fri, Sep 30, 2022 at 04:39:25PM -0400, Jason Merrill wrote:
* fold-const.h (simple_operand_p_2): Declare.
This needs a better name if it's going to be a public interface.
The usage also needs rationale for why this is the right predicate for
a
On 9/30/22 03:20, Jakub Jelinek wrote:
On Wed, Sep 28, 2022 at 08:19:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
Another case are the following 3 snippets:
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
# error "_Float128X supported but no constant suffix"
# else
# define __f128x(x
On 10/4/22 05:06, Jakub Jelinek wrote:
On Fri, Sep 30, 2022 at 04:08:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
On Fri, Sep 30, 2022 at 09:49:08AM -0400, Jason Merrill wrote:
The comment from Apple on the ABI mangling proposal suggests to me that we
might want to delay enabling C++ std::b
On 10/3/22 02:08, Eugene Rozenfeld wrote:
This change is based on commit 1e6c4a7a8fb8e20545bb9f9032d3854f3f794c18
by Dehao Chen in vendors/google/heads/gcc-4_8.
Tested on x86_64-pc-linux-gnu.
Brief rationale for the change?
gcc/ChangeLog:
* tree-cfg.cc (assign_discriminators): Set d
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
In the testcase the elaboration of the array init that happens at genericize
time was getting the location info for the end of the function; fixed by
doing the expansion at the location of the original expression.
PR c++/107154
gcc
On 10/5/22 05:55, Jakub Jelinek wrote:
On Tue, Oct 04, 2022 at 04:42:04PM -0400, Jason Merrill wrote:
It could choose which function to call based on whether the constexpr_ctx
parameter is null?
Done, though it needs to be in constexpr.cc then because struct
constexpr_ctx and cxx_eval_constant
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
I was wondering how lvalue_kind handles VIEW_CONVERT_EXPR; in cases where
the type actually changes, it should have the same prvalue->xvalue effect as
ARRAY_REF, since we need to materialize a temporary to get an object we can
reinterpret as
On 10/5/22 09:47, Jakub Jelinek wrote:
On Tue, Oct 04, 2022 at 05:50:50PM -0400, Jason Merrill wrote:
Another question is the suffixes of the builtins. For now I have added
bf16 suffix and enabled the builtins with !both_p, so one always needs to
use __builtin_* form for them. None of the GCC
On 10/5/22 17:27, Marek Polacek wrote:
This PR reports that
struct Base {};
struct Derived : Base {};
static_assert(__reference_constructs_from_temporary(Base const&, Derived));
doesn't pass, which it should: it's just like
const Base& b(Derived{});
where we bind 'b' to the Base s
On 10/5/22 22:02, Patrick Palka wrote:
Roughly speaking, optimize_specialization_lookup_p returns true
for a non-template member function of a class template, e.g.
template struct A { int f(); };
The idea behind the optimization in question seems to be that if we want
to look up the speciali
On 10/5/22 08:04, Jakub Jelinek wrote:
Hi!
The following patch uses the new lookup_attribute overload and extra
tests to avoid emitting weird warnings on foreign namespace attributes
which we should just ignore (perhaps with a warning), but shouldn't
imply any meaning to them just because they h
On 10/6/22 10:49, Marek Polacek wrote:
On Wed, Oct 05, 2022 at 08:25:29PM -0400, Jason Merrill wrote:
On 10/5/22 17:27, Marek Polacek wrote:
This PR reports that
struct Base {};
struct Derived : Base {};
static_assert(__reference_constructs_from_temporary(Base const&, Derived));
d
On 10/6/22 13:20, Jakub Jelinek wrote:
On Thu, Oct 06, 2022 at 09:42:47AM -0400, Jason Merrill wrote:
- tree t = lookup_attribute ("fallthrough", attr);
+ tree t = lookup_attribute (NULL, "fallthrough", attr);
+ if (t == NULL_TREE)
+t = lookup_attribute ("gnu", "fallthrough", attr);
May
On 10/6/22 10:34, Paul Iannetta wrote:
Hi,
Presently, GCC supports target address spaces as a GNU extension (cf.
`info -n "(gcc)Named Address Spaces"`). This is however supported
only by the C frontend, which is a bit sad, since all the GIMPLE
machinery is readily available and, moreover, LLVM
On 10/6/22 13:51, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 10:58:44AM -0400, Jason Merrill wrote:
On 10/6/22 10:49, Marek Polacek wrote:
On Wed, Oct 05, 2022 at 08:25:29PM -0400, Jason Merrill wrote:
On 10/5/22 17:27, Marek Polacek wrote:
This PR reports that
struct Base {};
st
Tested x86_64-pc-linux-gnu, OK for trunk?
-- >8 --
In this testcase, we were optimizing away the temporary for f(), but
C++17 and above are clear that there is a temporary, and because its
destructor has visible side-effects we can't optimize it away under the
as-if rule. So disable this optimiz
On 10/6/22 14:29, Jakub Jelinek wrote:
On Thu, Oct 06, 2022 at 01:30:18PM -0400, Jason Merrill wrote:
Yes, except I was thinking the new function would take the attribute
TREE_LIST as its parameter so that all the callers don't have to also call
get_attribute_namespace.
Ok, here it is in patch
On 10/4/22 19:06, Marek Polacek wrote:
On Fri, Sep 30, 2022 at 09:12:24AM -0400, Jason Merrill wrote:
On 9/29/22 18:49, Marek Polacek wrote:
When getting the name of an attribute, we ought to use
get_attribute_name, which handles both [[ ]] and __attribute__(())
forms. Failure to do so may res
On 10/3/22 23:53, Jason Merrill wrote:
On 9/30/22 18:50, Iain Sandoe wrote:
Hi Jason,
On 30 Sep 2022, at 23:06, Jason Merrill wrote:
You can't use CONVERT_EXPR to convert between two class types, and it
was
breaking copy elision.
Unfortunately, this patch breaks symmetric-transfer-00-basi
On 10/6/22 17:43, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 02:00:40PM -0400, Jason Merrill wrote:
On 10/6/22 13:51, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 10:58:44AM -0400, Jason Merrill wrote:
On 10/6/22 10:49, Marek Polacek wrote:
On Wed, Oct 05, 2022 at 08:25:29PM -0400, Jason Me
On 10/6/22 23:50, Eugene Rozenfeld wrote:
Thank you for the review Jason.
I fixed formatting and updated the commit description:
OK.
Call statements are possible split points of a basic block so they may end up
in different basic blocks by the time pass_ipa_auto
On 10/7/22 08:27, Nathan Sidwell wrote:
VAR and FIELD decls can become part of a lambda context, when the
lambda is 'attached' to that entity (It's a C++20 ODR thing that was
discovered with modules, but is actually separate.) We were not
marking those decls as substitution candidates, leading t
On 10/6/22 22:12, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 05:42:41PM -0400, Jason Merrill wrote:
On 10/4/22 19:06, Marek Polacek wrote:
On Fri, Sep 30, 2022 at 09:12:24AM -0400, Jason Merrill wrote:
On 9/29/22 18:49, Marek Polacek wrote:
When getting the name of an attribute, we ought to
On 10/7/22 12:10, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 06:03:57PM -0400, Jason Merrill wrote:
On 10/6/22 17:43, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 02:00:40PM -0400, Jason Merrill wrote:
On 10/6/22 13:51, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 10:58:44AM -0400, Jason Me
On 10/7/22 17:26, Marek Polacek wrote:
On Fri, Oct 07, 2022 at 01:01:35PM -0400, Jason Merrill wrote:
On 10/7/22 12:10, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 06:03:57PM -0400, Jason Merrill wrote:
On 10/6/22 17:43, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 02:00:40PM -0400, Jason Me
On 10/7/22 17:08, Marek Polacek wrote:
On Fri, Oct 07, 2022 at 12:17:34PM -0400, Jason Merrill wrote:
On 10/6/22 22:12, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 05:42:41PM -0400, Jason Merrill wrote:
On 10/4/22 19:06, Marek Polacek wrote:
On Fri, Sep 30, 2022 at 09:12:24AM -0400, Jason Me
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
A discussion at Cauldron made me think that with the formalization of copy
elision in C++17, we should be able to determine before optimization which
TARGET_EXPRs will become temporaries and which are initializers. This patch
implements tha
On 10/7/22 18:16, Marek Polacek wrote:
On Fri, Oct 07, 2022 at 05:56:18PM -0400, Jason Merrill wrote:
On 10/7/22 17:08, Marek Polacek wrote:
On Fri, Oct 07, 2022 at 12:17:34PM -0400, Jason Merrill wrote:
On 10/6/22 22:12, Marek Polacek wrote:
On Thu, Oct 06, 2022 at 05:42:41PM -0400, Jason Me
On 10/9/22 12:12, Paul Iannetta wrote:
Hi,
On Thu, Oct 06, 2022 at 01:34:40PM -0400, Jason Merrill wrote:
[snip]
Hmm? We mangle __restrict:
void f(int *__restrict *p) { } // _Z1fPrPi
Indeed, I have overlooked that point. Thank you for pointing it out.
but cv-qualifiers (including restr
On 10/10/22 15:18, Marek Polacek wrote:
On Mon, Oct 10, 2022 at 10:49:34AM -0400, Jason Merrill wrote:
On 10/7/22 18:16, Marek Polacek wrote:
On Fri, Oct 07, 2022 at 05:56:18PM -0400, Jason Merrill wrote:
On 10/7/22 17:08, Marek Polacek wrote:
On Fri, Oct 07, 2022 at 12:17:34PM -0400, Jason M
On 9/28/22 17:26, Marek Polacek wrote:
This patch removes the two-stage overload resolution when performing
implicit move, whereby the compiler does two separate overload resolutions:
one treating the operand as an rvalue, and then (if that resolution fails)
another one treating the operand as an
On 10/4/22 11:11, Ben Boeckel wrote:
This patch adds initial support for ISO C++'s [P1689R5][], a format for
describing C++ module requirements and provisions based on the source
code. This is required because compiling C++ with modules is not
embarrassingly parallel and need to be ordered to ens
On 10/4/22 11:12, Ben Boeckel wrote:
This patch implements support for [P1689R5][] to communicate to a build
system the C++20 module dependencies to build systems so that they may
build `.gcm` files in the proper order.
Thanks!
Support is communicated through the following three new flags:
-
On 10/10/22 04:54, Jakub Jelinek via Gcc-patches wrote:
Hi!
My earlier patches gimplify the simplest non-side-effects assumptions
into if (cond) ; else __builtin_unreachable (); and throw the rest
on the floor.
The following patch attempts to do something with the rest too.
For -O0, it actually
On 10/10/22 20:36, Eugene Rozenfeld wrote:
The bug was introduced in f30e9fd33e56a5a721346ea6140722e1b193db42.
A variable (cur_locus_e) was incorrectly declared inside a loop.
I also moved two other declarations (last and locus) down to make
the code more clear.
Tested on x86_64-pc-linux-gnu.
On 10/11/22 16:00, Marek Polacek wrote:
Since r12-8066, in cxx_eval_vec_init we perform expand_vec_init_expr
while processing the default argument in this test.
Hmm, why are we calling cxx_eval_vec_init during parsing of the default
argument? In particular, any expansion that depends on the e
On 10/11/22 17:58, Iain Sandoe wrote:
Tested on x86_64-darwin19, OK for master?
thanks
Iain
-- >8 --
Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
is set properly on target exprs. The code here has a mixture of APIs used
to build inits. This patch changes that to us
On 10/11/22 18:17, Iain Sandoe wrote:
Hi Jason
On 11 Oct 2022, at 23:06, Jason Merrill wrote:
On 10/11/22 17:58, Iain Sandoe wrote:
Tested on x86_64-darwin19, OK for master?
thanks
Iain
-- >8 --
Now we have the TARGET_EXPR_ELIDING_P flag, it is important to ensure it
is set properly on targe
On 10/11/22 18:03, Paul Iannetta wrote:
Thank you very much for the comments.
On Mon, Oct 10, 2022 at 03:20:13PM -0400, Jason Merrill wrote:
On 10/9/22 12:12, Paul Iannetta wrote:
That's a nice feature! LLVM is using AS to mangle the
address-name qualified types but that would have required an
On 3/1/22 14:33, Jakub Jelinek wrote:
Hi!
The r12-7287-g1b71bc7c8b18bd1b change improved the -Wdeprecated
warning for C++, but regressed it for C, in particular in
gcc.dg/deprecated.c testcase we now report a type that actually isn't
deprecated as deprecated instead of the one that is deprecated
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 explicit
deduction guides when performing CTAD for a temp
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 non-template trees.
Maybe we want to change instantiate
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 context (via the LOOKUP_ONLYCONVERTING
flag), which causes do_class_dedu
On 2/27/22 18:52, Jason Merrill wrote:
The patch for PR90451 deferred marking to the point of actual use; we missed
this one because of the parens.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104618
gcc/cp/ChangeLog:
* typeck.cc (cp_build_addr_expr_1): Also
m
On 3/7/22 08:33, Roger Sayle wrote:
This patch fixes PR c++/96437 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03
On 3/7/22 08:04, Roger Sayle wrote:
This patch fixes PR c++/96329 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03
On 3/7/22 08:55, Roger Sayle wrote:
This patch fixes PR c++/96440 which is an ICE-on-invalid-code regression
affecting mainline.
This patch has been tested on x86_64-pc-linux-gnu, enabling languages
c and c++, with make bootstrap and make -k check with no new failures.
Ok for mainline?
2022-03
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 we're failing to communicate to cp_finish_decl from tsubst_expr
that we're in a copy-initi
On 3/8/22 05:32, Jakub Jelinek wrote:
On Tue, Mar 08, 2022 at 10:23:28AM +0100, Richard Biener wrote:
On Tue, Mar 8, 2022 at 8:27 AM Jakub Jelinek via Gcc-patches
On the following testcase, we emit "did you mean '__dt '?" in the error
message. "__dt " shows there because it is dtor_identifier,
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
Hmm, that now strikes me as a problematic interface, as we don't know whether
what w
On 3/2/22 14:31, Marek Polacek wrote:
104752 points out that
template
concept C = true;
auto y = C auto(1);
is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type conversion,
T is the specified type, which shall be auto." which doesn't allow
type-constraint auto.
Bootstrap
On 3/2/22 14:31, Marek Polacek wrote:
Attributes deprecated and unavailable are largely the same, except
that the former produces a warning whereas the latter produces an error.
So is_late_template_attribute should treat them the same. Confirmed by
Iain that this divergence is not intentional:
<
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 Fri, 4 Mar 2022, Jason Merrill wrote:
On 3/4/22 14:24, Patrick Palka wrote:
Here we're fa
On 3/3/22 16:06, Patrick Palka wrote:
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.
On 3/8/22 16:57, Patrick Palka wrote:
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
Hm
On 3/8/22 17:14, Marek Polacek wrote:
In r10-6329 I tried to optimize the number of calls to v_d_e_p in
convert_nontype_argument by remembering whether the expression was
value-dependent in a bool flag. I did that wrongly assuming that its
value-dependence will not be changed by build_converted_
On 3/8/22 17:17, Patrick Palka wrote:
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 Fri, 4 Mar
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 least when it appears in a CTAD-enabled context.
This pat
On 3/2/22 05:22, Jakub Jelinek wrote:
Hi!
As mentioned in the PR, different standards have different definition
on what is an UB left shift. They all agree on out of bounds (including
negative) shift count.
The rules used by ubsan are:
C99-C2x ((unsigned) x >> (uprecm1 - y)) != 0 then UB
C++11-
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 an operation that
is never interesting to debug.
This
On 3/1/22 17:12, Marek Polacek wrote:
On Mon, Feb 28, 2022 at 12:31:37PM -0400, Jason Merrill wrote:
On 2/22/22 17:46, Marek Polacek wrote:
Here we have a forward declaration of Parameter for which we create
an implicit typedef, which is a TYPE_DECL. Then, when looking it up
at template defini
On 3/9/22 14:35, Roger Sayle wrote:
Hi Jason,
Very many thanks for your reviews/approvals of these ICE-on-invalid-code fixes.
+ if (TREE_VALUE (new_parm) != error_mark_node)
+DECL_VIRTUAL_P (TREE_VALUE (new_parm)) = true;
Hmm, I wonder about returning early if there was an error, but t
On 3/9/22 14:09, Marek Polacek wrote:
This is an ICE-on-invalid with "auto operator delete[] (void *)" whose
return type must be void. The return type is checked in coerce_delete_type
but we never got there in this test, because we took the wrong path in
grokdeclarator, set type to error_mark_no
On 3/9/22 11:22, Marek Polacek wrote:
On Tue, Mar 08, 2022 at 02:47:42PM -0500, Jason Merrill wrote:
On 3/2/22 14:31, Marek Polacek wrote:
104752 points out that
template
concept C = true;
auto y = C auto(1);
is ill-formed as per [dcl.type.auto.deduct]: "For an explicit type conve
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, we need to permit a
typename-specifier to resolve to a template as per
On 2/26/22 19:55, Roger Sayle wrote:
This is a fix for PR c++/39751 which is an ICE-on-invalid regression in
the C++ parser after encountering the end of file. The one line change
is to check that the tokens cached in DECL_PENDING_INLINE_INFO haven't
been purged before processing them in cp_par
On 2/22/22 08:02, Roger Sayle wrote:
This patch resolves PR c++/96442, another ICE-after-error regression.
In this case, invalid code attempts to use a non-integral type as the
underlying type for an enumeration (a record_type in the example given
in the bugzilla PR), for which the parser emits
On 2/21/22 08:17, Roger Sayle wrote:
This patch resolves PR c++/95999 which is an ICE-after-error regression
in the g++ front-end. When parsing an enumerator list, the C++ parser
assumes that cp_parser_constant_expression always returns either an
INTEGER_CST or error_mark_node, but in testcase
On 2/28/22 03:52, Roger Sayle wrote:
This patch resolves PR c++/84964 which is an ICE in the middle-end after
emitting a "sorry, unimplemented" message, and is a regression from
earlier releases of GCC. This issue is that after encountering a
function call requiring an unreasonable amount of st
On 3/10/22 04:34, Jakub Jelinek wrote:
Hi!
wg21.link/p2128 removed "with exactly one parameter" from over.sub
section. grok_op_properties has for that the last 2 lines in:
case OVL_OP_FLAG_BINARY:
if (arity != 2)
{
if (operator_code == ARRAY_REF && cxx_dialect >=
On 3/2/22 19:15, Martin Sebor wrote:
The -Wdangling-pointer code tests the EDGE_DFS_BACK but the pass never
calls the mark_dfs_back_edges() function that initializes the bit (I
didn't know about it). As a result the bit is not set when expected,
which can cause false positives under the right co
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 it depends only on the innermost argument
T we use a single-level argument
On 3/1/22 00:14, Patrick Palka wrote:
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 | r
On 3/1/22 00:10, Patrick Palka wrote:
On Tue, 19 Jan 2021, Jason Merrill wrote:
On 1/13/21 12:05 PM, Patrick Palka wrote:
In the below testcase, the expression of the atomic constraint after
substitution is (int *) NON_LVALUE_EXPR <1> != 0B which is not a C++
constant expression, but its TREE_
On 2/17/22 23:30, Zhao Wei Liew wrote:
On Fri, 18 Feb 2022 at 08:32, Zhao Wei Liew wrote:
+/* Test non-empty class */
+void f2(B b1, B b2)
+{
+ if (b1 = 0); /* { dg-warning "suggest parentheses" } */
+ if (b1 = 0.); /* { dg-warning "suggest parentheses" } */
+ if (b1 = b2); /* { dg-warning "s
On 3/11/22 11:46, Patrick Palka wrote:
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 (in
On 3/10/22 16:57, Patrick Palka wrote:
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,
On 3/10/22 15:30, Patrick Palka wrote:
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 assum
On 3/10/22 18:04, Marek Polacek wrote:
Since r9-6073 cxx_eval_store_expression preevaluates the value to
be stored, and that revealed a crash where a template code (here,
code=IMPLICIT_CONV_EXPR) leaks into cxx_eval*.
It happens because we're performing build_vec_init while processing
a template
On 3/10/22 12:41, Patrick Palka wrote:
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 test
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 means it comes with bloated debug info, which
persists even after the call
On 2/21/22 04:25, Jakub Jelinek wrote:
Hi!
The new expression constant expression evaluation right now tries to
deduce how many elts the array it uses for the heap or heap [] vars
should have (or how many elts should its trailing array have if it has
cookie at the start). As new is lowered at t
On 2/11/22 14:55, Jakub Jelinek wrote:
Hi!
As mentioned by Jason in the PR, non-trivially-copyable types (or non-POD
for purposes of layout?) types can be base classes of derived classes in
which the padding in those non-trivially-copyable types can be redused for
some real data members or even
On 3/14/22 13:24, 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 (
On 3/14/22 13:13, Patrick Palka wrote:
On Fri, 11 Mar 2022, Jason Merrill wrote:
On 3/10/22 11:27, Patrick Palka wrote:
On Wed, 9 Mar 2022, Jason Merrill wrote:
On 3/1/22 18:08, Patrick Palka wrote:
A well-formed call to std::move/forward is equivalent to a cast, but the
former being a func
On 3/12/22 14:22, Jakub Jelinek wrote:
Hi!
We ICE on the following testcase, because we tentatively parse it multiple
times and the erroneous attribute syntax results in
cp_parser_skip_to_end_of_statement, which when seeing CPP_PRAGMA (can be
any deferred one, OpenMP/OpenACC/ivdep etc.) it calls
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 Wed, 9 Mar 2022, Jason Merrill wrote:
On 3/1/22 18:08, Patrick Palka wrote:
A well-f
On 3/15/22 08:32, Jakub Jelinek wrote:
On Fri, Feb 11, 2022 at 12:27:49PM -0500, Jason Merrill wrote:
Yes, that's what the above code would correctly do if TYPE were the
pointer-to-method type. It's wrong for this case because TYPE is unrelated
to TREE_TYPE (field).
I think the problem is just
On 3/15/22 07:44, Jakub Jelinek wrote:
On Fri, Mar 11, 2022 at 11:28:09PM -0500, Jason Merrill wrote:
@@ -7264,9 +7265,66 @@ cxx_eval_constant_expression (const cons
DECL_NAME (var)
= (DECL_NAME (var) == heap_uninit_identifier
? heap_identifier : heap_v
On 3/15/22 13:09, Patrick Palka wrote:
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 Wed
On 3/15/22 13:18, Patrick Palka wrote:
As a followup to r12-7656-gffe9c0a0d3564a, this minor patch condenses
the handling of ambiguity and access w.r.t. the value of 'protect' so
that it more clearly matches the function comment.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look
On 3/14/22 02:36, Zhao Wei Liew via Gcc-patches wrote:
This patch adds a warning when casting "this" to Derived* in the Base
class constructor and destructor. I've added the warning under the
-Wextra flag as I can't find a more appropriate flag for it.
It's generally best to add a new warning
On 3/16/22 17:18, Marek Polacek wrote:
Zero-length pack expansions are treated as if no list were provided
at all, that is, with
template struct S { };
template
void g() {
S...>;
}
g will result in S<>. In the following test we have something
similar:
template
using Is
On 3/16/22 12:55, Jakub Jelinek wrote:
On Tue, Mar 15, 2022 at 04:19:05PM -0400, Jason Merrill wrote:
But if you strongly prefer it that way, I can do that.
Note, probably not 3 new args but 4, depends on whether we could turn
all those cases where the tree arg0 = CALL_EXPR_ARG (oldop, 0);
is do
On 3/15/22 12:06, Jakub Jelinek wrote:
On Tue, Mar 15, 2022 at 11:57:22AM -0400, Jason Merrill wrote:
The intent of r11-6729 is that it prints something that helps user to figure
out what exactly is being accessed.
When we find a unique non-static data member that is being accessed, even
when we
601 - 700 of 2965 matches
Mail list logo
