Use of compound_literal_expr in c vs target_expr in c++ for compound literals

[Fariborz Jahanian <fjahanian at apple dot com>]

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 (fjahanian@apple.com)