* C++ PATCHes relating to c++/48834, c++/40975 (array new)
@ 2011-05-02 21:58 Jason Merrill
2011-05-02 22:23 ` Eric Botcazou
0 siblings, 1 reply; 15+ messages in thread
From: Jason Merrill @ 2011-05-02 21:58 UTC (permalink / raw)
To: gcc-patches List
[-- Attachment #1: Type: text/plain, Size: 801 bytes --]
So, the problem in 48834 was that we had specified a particular target
for the vec initialization, but it was getting clobbered by ending up on
the rhs of an INIT_EXPR. So 48834.patch avoids that.
But Diego doesn't think there was any real reason to abort on trying to
copy a STATEMENT_LIST, so it seems to me that we could revert my earlier
patch for 40975 and just add support for copying STATEMENT_LIST. So
40975-2.patch adds that support. I haven't attached a patch to revert
my earlier 40975 patch.
Some of the incidental changes from my earlier patch seem independently
useful, so I'm reapplying those in vec-sfinae.patch.
Tested x86_64-pc-linux-gnu, applying to trunk. Also applying
40975-2.patch to 4.4, 4.5 and 4.6; it doesn't fix the bug in 4.3 so I'm
not applying it there.
[-- Attachment #2: 48834.patch --]
[-- Type: text/plain, Size: 1557 bytes --]
commit 41d391e1683e6ed7e28ad31f41732b3f4b691baa
Author: Jason Merrill <jason@redhat.com>
Date: Mon May 2 01:36:01 2011 -0400
PR c++/48834
* tree.c (build_vec_init_expr): Set TREE_SIDE_EFFECTS.
Protect an explicit target.
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 2eaa1db..fff3fbf 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -564,6 +564,7 @@ build_vec_init_expr (tree target, tree init, tree nelts,
elt_init = build_vec_init_elt (type, init, complain);
init = build3 (VEC_INIT_EXPR, type, slot, init, nelts);
+ TREE_SIDE_EFFECTS (init) = true;
SET_EXPR_LOCATION (init, input_location);
if (cxx_dialect >= cxx0x
@@ -571,7 +572,11 @@ build_vec_init_expr (tree target, tree init, tree nelts,
VEC_INIT_EXPR_IS_CONSTEXPR (init) = true;
VEC_INIT_EXPR_VALUE_INIT (init) = value_init;
- if (slot != target)
+ if (slot == target)
+ /* If we specified what array we're initializing, make sure
+ we don't override that in cp_gimplify_init_expr. */
+ init = cp_build_compound_expr (init, slot, complain);
+ else
{
init = build_target_expr (slot, init, complain);
TARGET_EXPR_IMPLICIT_P (init) = 1;
diff --git a/gcc/testsuite/g++.dg/init/new31.C b/gcc/testsuite/g++.dg/init/new31.C
new file mode 100644
index 0000000..33c94aa
--- /dev/null
+++ b/gcc/testsuite/g++.dg/init/new31.C
@@ -0,0 +1,18 @@
+// PR c++/48834
+// { dg-options -Wuninitialized }
+// { dg-do run }
+
+struct S
+{
+ S ():i (0)
+ {
+ }
+ int i;
+};
+
+int
+main ()
+{
+ S *s = new S[2];
+ return 0;
+}
[-- Attachment #3: 40975-2.patch --]
[-- Type: text/plain, Size: 1279 bytes --]
commit 98011319607130da27331a5f1b763ba8ce741734
Author: Jason Merrill <jason@redhat.com>
Date: Mon May 2 16:02:29 2011 -0400
PR c++/40975
* tree-inline.c (copy_tree_r): Handle STATEMENT_LIST.
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 5da4a12..3777675 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -4271,14 +4271,26 @@ copy_tree_r (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
CONSTRUCTOR_ELTS (*tp));
*tp = new_tree;
}
+ else if (code == STATEMENT_LIST)
+ {
+ /* We used to just abort on STATEMENT_LIST, but we can run into them
+ with statement-expressions (c++/40975). */
+ tree new_list = alloc_stmt_list ();
+ tree_stmt_iterator i = tsi_start (*tp);
+ tree_stmt_iterator j = tsi_last (new_list);
+ for (; !tsi_end_p (i); tsi_next (&i))
+ {
+ tree stmt = tsi_stmt (i);
+ tsi_link_after (&j, stmt, TSI_CONTINUE_LINKING);
+ }
+ *tp = new_list;
+ }
else if (TREE_CODE_CLASS (code) == tcc_type)
*walk_subtrees = 0;
else if (TREE_CODE_CLASS (code) == tcc_declaration)
*walk_subtrees = 0;
else if (TREE_CODE_CLASS (code) == tcc_constant)
*walk_subtrees = 0;
- else
- gcc_assert (code != STATEMENT_LIST);
return NULL_TREE;
}
[-- Attachment #4: vec-sfinae.patch --]
[-- Type: text/plain, Size: 4822 bytes --]
commit 6f60af2d7324b81f4b524c34c321280e4874c2ee
Author: Jason Merrill <jason@redhat.com>
Date: Mon May 2 17:02:10 2011 -0400
* tree.c (build_vec_init_expr): Take complain parm.
(build_vec_init_elt): Likewise. Free arg vector.
(diagnose_non_constexpr_vec_init, build_array_copy): Adjust.
* cp-tree.h (VEC_INIT_EXPR_SLOT): Use VEC_INIT_EXPR_CHECK.
(VEC_INIT_EXPR_INIT): Likewise.
Adjust build_vec_init_expr declaration.
* init.c (perform_member_init): Adjust.
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 9bad404..961581e 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -2896,8 +2896,8 @@ more_aggr_init_expr_args_p (const aggr_init_expr_arg_iterator *iter)
(arg) = next_aggr_init_expr_arg (&(iter)))
/* VEC_INIT_EXPR accessors. */
-#define VEC_INIT_EXPR_SLOT(NODE) TREE_OPERAND (NODE, 0)
-#define VEC_INIT_EXPR_INIT(NODE) TREE_OPERAND (NODE, 1)
+#define VEC_INIT_EXPR_SLOT(NODE) TREE_OPERAND (VEC_INIT_EXPR_CHECK (NODE), 0)
+#define VEC_INIT_EXPR_INIT(NODE) TREE_OPERAND (VEC_INIT_EXPR_CHECK (NODE), 1)
/* Indicates that a VEC_INIT_EXPR is a potential constant expression.
Only set when the current function is constexpr. */
@@ -5420,7 +5420,7 @@ extern tree get_target_expr_sfinae (tree, tsubst_flags_t);
extern tree build_cplus_array_type (tree, tree);
extern tree build_array_of_n_type (tree, int);
extern tree build_array_copy (tree);
-extern tree build_vec_init_expr (tree, tree);
+extern tree build_vec_init_expr (tree, tree, tsubst_flags_t);
extern void diagnose_non_constexpr_vec_init (tree);
extern tree hash_tree_cons (tree, tree, tree);
extern tree hash_tree_chain (tree, tree);
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 50dbcc9..7a7379e 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -506,7 +506,7 @@ perform_member_init (tree member, tree init)
/* mem() means value-initialization. */
if (TREE_CODE (type) == ARRAY_TYPE)
{
- init = build_vec_init_expr (type, init);
+ init = build_vec_init_expr (type, init, tf_warning_or_error);
init = build2 (INIT_EXPR, type, decl, init);
finish_expr_stmt (init);
}
@@ -543,7 +543,7 @@ perform_member_init (tree member, tree init)
|| same_type_ignoring_top_level_qualifiers_p (type,
TREE_TYPE (init)))
{
- init = build_vec_init_expr (type, init);
+ init = build_vec_init_expr (type, init, tf_warning_or_error);
init = build2 (INIT_EXPR, type, decl, init);
finish_expr_stmt (init);
}
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index dfd11ad..0f2f86c 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -475,7 +475,7 @@ build_cplus_new (tree type, tree init, tsubst_flags_t complain)
another array to copy. */
static tree
-build_vec_init_elt (tree type, tree init)
+build_vec_init_elt (tree type, tree init, tsubst_flags_t complain)
{
tree inner_type = strip_array_types (type);
VEC(tree,gc) *argvec;
@@ -485,7 +485,7 @@ build_vec_init_elt (tree type, tree init)
/* No interesting initialization to do. */
return integer_zero_node;
else if (init == void_type_node)
- return build_value_init (inner_type, tf_warning_or_error);
+ return build_value_init (inner_type, complain);
gcc_assert (init == NULL_TREE
|| (same_type_ignoring_top_level_qualifiers_p
@@ -499,9 +499,12 @@ build_vec_init_elt (tree type, tree init)
dummy = move (dummy);
VEC_quick_push (tree, argvec, dummy);
}
- return build_special_member_call (NULL_TREE, complete_ctor_identifier,
+ init = build_special_member_call (NULL_TREE, complete_ctor_identifier,
&argvec, inner_type, LOOKUP_NORMAL,
- tf_warning_or_error);
+ complain);
+ release_tree_vector (argvec);
+
+ return init;
}
/* Return a TARGET_EXPR which expresses the initialization of an array to
@@ -509,11 +512,11 @@ build_vec_init_elt (tree type, tree init)
from another array of the same type. */
tree
-build_vec_init_expr (tree type, tree init)
+build_vec_init_expr (tree type, tree init, tsubst_flags_t complain)
{
tree slot;
bool value_init = false;
- tree elt_init = build_vec_init_elt (type, init);
+ tree elt_init = build_vec_init_elt (type, init, complain);
if (init == void_type_node)
{
@@ -550,14 +553,14 @@ diagnose_non_constexpr_vec_init (tree expr)
else
init = VEC_INIT_EXPR_INIT (expr);
- elt_init = build_vec_init_elt (type, init);
+ elt_init = build_vec_init_elt (type, init, tf_warning_or_error);
require_potential_constant_expression (elt_init);
}
tree
build_array_copy (tree init)
{
- return build_vec_init_expr (TREE_TYPE (init), init);
+ return build_vec_init_expr (TREE_TYPE (init), init, tf_warning_or_error);
}
/* Build a TARGET_EXPR using INIT to initialize a new temporary of the
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-02 21:58 C++ PATCHes relating to c++/48834, c++/40975 (array new) Jason Merrill
@ 2011-05-02 22:23 ` Eric Botcazou
2011-05-03 5:05 ` Jason Merrill
0 siblings, 1 reply; 15+ messages in thread
From: Eric Botcazou @ 2011-05-02 22:23 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
> But Diego doesn't think there was any real reason to abort on trying to
> copy a STATEMENT_LIST, so it seems to me that we could revert my earlier
> patch for 40975 and just add support for copying STATEMENT_LIST. So
> 40975-2.patch adds that support.
FWIW this assertion caught an impressive number of bugs in Ada over the years
related to COND_EXPR: when they are incorrectly shared, gimplifying them on
one side creates a STATEMENT_LIST and stopped the copying on the other side.
I'm not sure you can copy statements if they have any side-effects; this looks
quite dangerous to me. Instead statement-expressions should be wrapped up in
a SAVE_EXPR/TARGET_EXPR to protect them and prevent copying.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-02 22:23 ` Eric Botcazou
@ 2011-05-03 5:05 ` Jason Merrill
2011-05-03 7:01 ` Eric Botcazou
0 siblings, 1 reply; 15+ messages in thread
From: Jason Merrill @ 2011-05-03 5:05 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc-patches
On 05/02/2011 06:23 PM, Eric Botcazou wrote:
> I'm not sure you can copy statements if they have any side-effects; this looks
> quite dangerous to me. Instead statement-expressions should be wrapped up in
> a SAVE_EXPR/TARGET_EXPR to protect them and prevent copying.
It sounds like Ada and C++ are using copy_tree_r in very different ways.
The use in C++ has to do with default arguments: we parse the expression
at the point of the function declaration, but whenever we want to use
the expression in a function call we need to make a deep copy of the
expression. In this case, we want to copy everything.
How is it used in Ada?
Jason
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-03 5:05 ` Jason Merrill
@ 2011-05-03 7:01 ` Eric Botcazou
2011-05-03 15:27 ` Jason Merrill
0 siblings, 1 reply; 15+ messages in thread
From: Eric Botcazou @ 2011-05-03 7:01 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
> How is it used in Ada?
The front-end doesn't use it directly, it's only used through the gimplifier
by the unsharing phase (unshare_body). We also have statement expressions.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-03 7:01 ` Eric Botcazou
@ 2011-05-03 15:27 ` Jason Merrill
2011-05-03 15:53 ` Eric Botcazou
0 siblings, 1 reply; 15+ messages in thread
From: Jason Merrill @ 2011-05-03 15:27 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc-patches
On 05/03/2011 03:00 AM, Eric Botcazou wrote:
>> How is it used in Ada?
>
> The front-end doesn't use it directly, it's only used through the gimplifier
> by the unsharing phase (unshare_body). We also have statement expressions.
In that case you wouldn't be affected by this patch; unshare_body uses
mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.
Jason
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-03 15:27 ` Jason Merrill
@ 2011-05-03 15:53 ` Eric Botcazou
2011-05-03 17:29 ` Jason Merrill
0 siblings, 1 reply; 15+ messages in thread
From: Eric Botcazou @ 2011-05-03 15:53 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
> In that case you wouldn't be affected by this patch; unshare_body uses
> mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.
Right, I added it precisely to support statement expressions in Ada (instead
of changing copy_tree_r) since we never want to copy them in the unsharing
phase. That's why I find the change to copy_tree_r questionable.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-03 15:53 ` Eric Botcazou
@ 2011-05-03 17:29 ` Jason Merrill
2011-05-03 18:32 ` RFA " Jason Merrill
2011-05-04 8:15 ` C++ PATCHes relating to c++/48834, c++/40975 (array new) Eric Botcazou
0 siblings, 2 replies; 15+ messages in thread
From: Jason Merrill @ 2011-05-03 17:29 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc-patches
On 05/03/2011 11:52 AM, Eric Botcazou wrote:
>> In that case you wouldn't be affected by this patch; unshare_body uses
>> mostly_copy_tree_r, which has its own special case for STATEMENT_LIST.
>
> Right, I added it precisely to support statement expressions in Ada (instead
> of changing copy_tree_r) since we never want to copy them in the unsharing
> phase. That's why I find the change to copy_tree_r questionable.
Well, let's look at the users of copy_tree_r.
cp/tree.c (bot_manip): The case I want to fix.
gimplify.c (mostly_copy_tree_r): Handles STATEMENT_LIST itself.
stor-layout.c (copy_self_referential_tree_r): Affected by the change.
Would you like me to add a gcc_unreachable() here?
tree-inline.c (copy_tree_body_r): already copies STATEMENT_LIST itself
(with a copy_statement_list function which I should use instead of
open-coding it again).
(copy_bind_expr): subroutine of copy_tree_body_r.
(unsave_r, remap_gimple_op_r): Handle STATEMENT_LIST themselves.
So, looks like one place that could have an undesired change in
behavior. I'll go ahead and add that assert.
Jason
^ permalink raw reply [flat|nested] 15+ messages in thread
* RFA Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-03 17:29 ` Jason Merrill
@ 2011-05-03 18:32 ` Jason Merrill
2011-05-16 17:00 ` PATCH to copy_statement_list for c++/47999 (ICE in testsuite on darwin) Jason Merrill
2011-05-04 8:15 ` C++ PATCHes relating to c++/48834, c++/40975 (array new) Eric Botcazou
1 sibling, 1 reply; 15+ messages in thread
From: Jason Merrill @ 2011-05-03 18:32 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
On 05/03/2011 01:28 PM, Jason Merrill wrote:
> stor-layout.c (copy_self_referential_tree_r): Affected by the change.
> Would you like me to add a gcc_unreachable() here?
>
> tree-inline.c (copy_tree_body_r): already copies STATEMENT_LIST itself
> (with a copy_statement_list function which I should use instead of
> open-coding it again).
Thus. Tested x86_64-pc-linux-gnu with c,ada,c++,fortran,java,lto,objc.
OK? I also removed the recursion from copy_statement_list because it
would just extra garbage STATEMENT_LISTs since they're already copied by
the normal walk_tree.
Jason
[-- Attachment #2: 40975-3.patch --]
[-- Type: text/plain, Size: 2102 bytes --]
commit 85aad99f6848bfaebbe5c794bf0a95c80e0f49cd
Author: Jason Merrill <jason@redhat.com>
Date: Tue May 3 13:19:10 2011 -0400
PR c++/40975
* tree-inline.c (copy_tree_r): Use copy_statement_list.
(copy_statement_list): Don't recurse.
* stor-layout.c (copy_self_referential_tree_r): Don't allow
STATEMENT_LIST.
diff --git a/gcc/stor-layout.c b/gcc/stor-layout.c
index ea0d44d..ecd1450 100644
--- a/gcc/stor-layout.c
+++ b/gcc/stor-layout.c
@@ -245,6 +245,8 @@ copy_self_referential_tree_r (tree *tp, int *walk_subtrees, void *data)
cannot always guarantee in practice. So punt in this case. */
else if (code == SAVE_EXPR)
return error_mark_node;
+ else if (code == STATEMENT_LIST)
+ gcc_unreachable ();
return copy_tree_r (tp, walk_subtrees, data);
}
diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c
index 3777675..ea7b7ab 100644
--- a/gcc/tree-inline.c
+++ b/gcc/tree-inline.c
@@ -662,8 +662,6 @@ copy_statement_list (tree *tp)
for (; !tsi_end_p (oi); tsi_next (&oi))
{
tree stmt = tsi_stmt (oi);
- if (TREE_CODE (stmt) == STATEMENT_LIST)
- copy_statement_list (&stmt);
tsi_link_after (&ni, stmt, TSI_CONTINUE_LINKING);
}
}
@@ -4272,19 +4270,9 @@ copy_tree_r (tree *tp, int *walk_subtrees, void *data ATTRIBUTE_UNUSED)
*tp = new_tree;
}
else if (code == STATEMENT_LIST)
- {
- /* We used to just abort on STATEMENT_LIST, but we can run into them
- with statement-expressions (c++/40975). */
- tree new_list = alloc_stmt_list ();
- tree_stmt_iterator i = tsi_start (*tp);
- tree_stmt_iterator j = tsi_last (new_list);
- for (; !tsi_end_p (i); tsi_next (&i))
- {
- tree stmt = tsi_stmt (i);
- tsi_link_after (&j, stmt, TSI_CONTINUE_LINKING);
- }
- *tp = new_list;
- }
+ /* We used to just abort on STATEMENT_LIST, but we can run into them
+ with statement-expressions (c++/40975). */
+ copy_statement_list (tp);
else if (TREE_CODE_CLASS (code) == tcc_type)
*walk_subtrees = 0;
else if (TREE_CODE_CLASS (code) == tcc_declaration)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-03 17:29 ` Jason Merrill
2011-05-03 18:32 ` RFA " Jason Merrill
@ 2011-05-04 8:15 ` Eric Botcazou
2011-05-04 15:49 ` Jason Merrill
1 sibling, 1 reply; 15+ messages in thread
From: Eric Botcazou @ 2011-05-04 8:15 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
> Well, let's look at the users of copy_tree_r.
>
> cp/tree.c (bot_manip): The case I want to fix.
Then I'd put the fix there. The old behaviour of copy_tree_r is IMO the most
sensible one and its callers should cope, as almost all already do it seems.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-04 8:15 ` C++ PATCHes relating to c++/48834, c++/40975 (array new) Eric Botcazou
@ 2011-05-04 15:49 ` Jason Merrill
2011-05-04 23:31 ` Eric Botcazou
0 siblings, 1 reply; 15+ messages in thread
From: Jason Merrill @ 2011-05-04 15:49 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc-patches
On 05/04/2011 04:12 AM, Eric Botcazou wrote:
>> Well, let's look at the users of copy_tree_r.
>>
>> cp/tree.c (bot_manip): The case I want to fix.
>
> Then I'd put the fix there. The old behaviour of copy_tree_r is IMO the most
> sensible one and its callers should cope, as almost all already do it seems.
Well, I disagree. STATEMENT_LISTs are just another kind of thing you
encounter in an expression; if a caller wants special handling, they can
arrange for it.
This is how things used to work before, but it broke when the tree-ssa
merge switched from using TREE_CHAIN on statements to a separate
STATEMENT_LIST.
Jason
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)
2011-05-04 15:49 ` Jason Merrill
@ 2011-05-04 23:31 ` Eric Botcazou
2011-05-05 14:24 ` copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)) Jason Merrill
0 siblings, 1 reply; 15+ messages in thread
From: Eric Botcazou @ 2011-05-04 23:31 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches
> Well, I disagree. STATEMENT_LISTs are just another kind of thing you
> encounter in an expression; if a caller wants special handling, they can
> arrange for it.
But you're unilaterally choosing one special handling (copying) among several
ones (copying, not copying, aborting) just because of one caller, for no good
reason IMO.
> This is how things used to work before, but it broke when the tree-ssa
> merge switched from using TREE_CHAIN on statements to a separate
> STATEMENT_LIST.
Well, the assertion certainly wasn't put there by accident.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 15+ messages in thread
* copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new))
2011-05-04 23:31 ` Eric Botcazou
@ 2011-05-05 14:24 ` Jason Merrill
2011-05-05 16:42 ` Richard Henderson
2011-05-07 19:52 ` Eric Botcazou
0 siblings, 2 replies; 15+ messages in thread
From: Jason Merrill @ 2011-05-05 14:24 UTC (permalink / raw)
To: Eric Botcazou; +Cc: gcc-patches, Richard Henderson
On 05/04/2011 06:57 PM, Eric Botcazou wrote:
> But you're unilaterally choosing one special handling (copying) among several
> ones (copying, not copying, aborting) just because of one caller, for no good
> reason IMO.
It seems pretty straightforward to me that a function named copy_tree_r
should copy everything that isn't always shared (like decls). It
already copies SAVE_EXPR, after all; how is copying STATEMENT_LIST going
to cause trouble in a context where copying SAVE_EXPR isn't?
>> This is how things used to work before, but it broke when the tree-ssa
>> merge switched from using TREE_CHAIN on statements to a separate
>> STATEMENT_LIST.
>
> Well, the assertion certainly wasn't put there by accident.
No, but the rationale isn't documented. It was added by the patch that
introduced STATEMENT_LIST,
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00879.html
but doesn't appear in the ChangeLog entry. I notice that in that patch
unsave_r copied STATEMENT_LIST, but now it doesn't. rth, do you happen
to remember why you put it there?
Jason
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new))
2011-05-05 14:24 ` copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)) Jason Merrill
@ 2011-05-05 16:42 ` Richard Henderson
2011-05-07 19:52 ` Eric Botcazou
1 sibling, 0 replies; 15+ messages in thread
From: Richard Henderson @ 2011-05-05 16:42 UTC (permalink / raw)
To: Jason Merrill; +Cc: Eric Botcazou, gcc-patches
On 05/05/2011 07:09 AM, Jason Merrill wrote:
> No, but the rationale isn't documented. It was added by the patch
> that introduced STATEMENT_LIST,
>
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg00879.html
>
> but doesn't appear in the ChangeLog entry. I notice that in that
> patch unsave_r copied STATEMENT_LIST, but now it doesn't. rth, do you
> happen to remember why you put it there?
No, I don't recall. I suspect that I put that in there while testing
in order to determine if I needed to support copying statement lists,
and it turned out that I didn't.
r~
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new))
2011-05-05 14:24 ` copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)) Jason Merrill
2011-05-05 16:42 ` Richard Henderson
@ 2011-05-07 19:52 ` Eric Botcazou
1 sibling, 0 replies; 15+ messages in thread
From: Eric Botcazou @ 2011-05-07 19:52 UTC (permalink / raw)
To: Jason Merrill; +Cc: gcc-patches, Richard Henderson
> It seems pretty straightforward to me that a function named copy_tree_r
> should copy everything that isn't always shared (like decls). It
> already copies SAVE_EXPR, after all; how is copying STATEMENT_LIST going
> to cause trouble in a context where copying SAVE_EXPR isn't?
OK, this can make sense, callers should handle special nodes like SAVE_EXPR,
TARGET_EXPR, STATEMENT_LIST, etc themselves. In light of this, they need to
be audited and adjusted, as you did already a few days ago. So I think I can
live with your 40975-3.patch in the end.
Thanks for your patience.
--
Eric Botcazou
^ permalink raw reply [flat|nested] 15+ messages in thread
* PATCH to copy_statement_list for c++/47999 (ICE in testsuite on darwin)
2011-05-03 18:32 ` RFA " Jason Merrill
@ 2011-05-16 17:00 ` Jason Merrill
0 siblings, 0 replies; 15+ messages in thread
From: Jason Merrill @ 2011-05-16 17:00 UTC (permalink / raw)
To: Diego Novillo; +Cc: gcc-patches
[-- Attachment #1: Type: text/plain, Size: 380 bytes --]
On 05/03/2011 02:18 PM, Jason Merrill wrote:
> I also removed the recursion from copy_statement_list because it
> would just extra garbage STATEMENT_LISTs since they're already copied by
> the normal walk_tree.
I was wrong about this, the recursion is necessary because
tsi_link_after destroys STATEMENT_LISTs.
Applying as obvious since it just restores code I removed before.
[-- Attachment #2: 47999.patch --]
[-- Type: text/x-patch, Size: 1674 bytes --]
commit 79330512f8ade4ecff47ab8cb8c050440d9648e0
Author: Jason Merrill <jason@redhat.com>
Date: Tue Mar 8 08:46:41 2011 -0500
PR c++/47999
* semantics.c (finish_call_expr): Preserve reference semantics
in templates.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 53497f3..ce24d46 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -2150,11 +2150,17 @@ finish_call_expr (tree fn, VEC(tree,gc) **args, bool disallow_virtual,
/* A call where the function is unknown. */
result = cp_build_function_call_vec (fn, args, complain);
- if (processing_template_decl)
+ if (processing_template_decl && result != error_mark_node)
{
+ if (TREE_CODE (result) == INDIRECT_REF)
+ result = TREE_OPERAND (result, 0);
+ gcc_assert (TREE_CODE (result) == CALL_EXPR
+ || TREE_CODE (fn) == PSEUDO_DTOR_EXPR
+ || errorcount);
result = build_call_vec (TREE_TYPE (result), orig_fn, orig_args);
KOENIG_LOOKUP_P (result) = koenig_p;
release_tree_vector (orig_args);
+ result = convert_from_reference (result);
}
return result;
diff --git a/gcc/testsuite/g++.dg/cpp0x/auto22.C b/gcc/testsuite/g++.dg/cpp0x/auto22.C
new file mode 100644
index 0000000..66630e5
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/auto22.C
@@ -0,0 +1,21 @@
+// PR c++/47999
+// { dg-options -std=c++0x }
+
+int& identity(int& i)
+{
+ return i;
+}
+
+// In a function template, auto type deduction works incorrectly.
+template <typename = void>
+void f()
+{
+ int i = 0;
+ auto&& x = identity(i); // Type of x should be `int&`, but it is `int&&`.
+}
+
+int main (int argc, char* argv[])
+{
+ f();
+ return 0;
+}
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-05-16 14:37 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-05-02 21:58 C++ PATCHes relating to c++/48834, c++/40975 (array new) Jason Merrill
2011-05-02 22:23 ` Eric Botcazou
2011-05-03 5:05 ` Jason Merrill
2011-05-03 7:01 ` Eric Botcazou
2011-05-03 15:27 ` Jason Merrill
2011-05-03 15:53 ` Eric Botcazou
2011-05-03 17:29 ` Jason Merrill
2011-05-03 18:32 ` RFA " Jason Merrill
2011-05-16 17:00 ` PATCH to copy_statement_list for c++/47999 (ICE in testsuite on darwin) Jason Merrill
2011-05-04 8:15 ` C++ PATCHes relating to c++/48834, c++/40975 (array new) Eric Botcazou
2011-05-04 15:49 ` Jason Merrill
2011-05-04 23:31 ` Eric Botcazou
2011-05-05 14:24 ` copy_tree_r and STATEMENT_LIST (was Re: C++ PATCHes relating to c++/48834, c++/40975 (array new)) Jason Merrill
2011-05-05 16:42 ` Richard Henderson
2011-05-07 19:52 ` Eric Botcazou
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).