gcc generates two separate trees for compound literals in c and c++.
As in this test case:
struct S {
int i,j;
};
void foo (struct S);
int main ()
{
foo((struct S){1,1});
}
In c it generates compound_literal_expr and in c++ it generates
target_expr. But gimplifier treats them differently in the following
areas:
1) in routine mostly_copy_tree_v we don;t copy target_expr but we do
copy compound_literal_expr. I see the following comment there:
/ * Similar to copy_tree_r() but do not copy SAVE_EXPR or
TARGET_EXPR nodes.
These nodes model computations that should only be done once. If we
were to unshare something like SAVE_EXPR(i++), the gimplification
process would create wrong code. */
Shouldn't compound_literal_expr be treated same as target_expr here?
2) gimplify_target_expr can be called more than once on the same
target_expr node because first time around its TARGET_EXPR_INITIAL is
set to NULL.
This works as a guard and prevents its temporary to be added to
the temporary list more than once (when call is made to
gimple_add_tmp_var).
On the other hand, such a guard does not exist for a
compound_literal_expr and when gimple_add_tmp_var is called, it
asserts. So, I added check for
!DECL_SEEN_IN_BIND_EXPR_P (decl) in
gimplify_compound_literal_expr before call to gimple_add_tmp_var is
made. As in the following diff:
% svn diff c-gimplify.c
Index: c-gimplify.c
===================================================================
--- c-gimplify.c (revision 116462)
+++ c-gimplify.c (working copy)
@@ -538,7 +538,7 @@
/* This decl isn't mentioned in the enclosing block, so add it to
the
list of temps. FIXME it seems a bit of a kludge to say that
anonymous artificial vars aren't pushed, but everything else
is. */
- if (DECL_NAME (decl) == NULL_TREE)
+ if (DECL_NAME (decl) == NULL_TREE && !DECL_SEEN_IN_BIND_EXPR_P
(decl))
gimple_add_tmp_var (decl);
This fixes the problem I am encountering. Is this a right approach in
situations when compound_literal_expr is used to represent a compound
literal in c and the expression is referenced in multiple places (by
hanging off a save_expr call_expr tree)?
- Thanks, Fariborz ([EMAIL PROTECTED])
