On Oct 1, 2005, at 8:41 PM, Andrew Pinski wrote:
On Oct 1, 2005, at 11:10 PM, Dale Johannesen wrote:
But better fix would be not call split_nonconstant_init_1 for
local decls and have the front-end produce a CONSTRUCTOR which is
just like what the C front-end produces.

I'll try it.

This patch should fix the problem and also fixes FSF PR 8045 at
the same time.  FSF PR 8045 is about an missing unused variable
causes by this code.

This patch causes us to be more similar with the C front-end.  It
should also cause us save us some compile time issue when gimplifing
and memory too.

Note I have not tested this yet by either looking at the code gen
or even compiling it.

I will be doing a bootstrap/test of this right now.

-- Pinski
Index: typeck2.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/typeck2.c,v
retrieving revision 1.192
diff -u -p -r1.192 typeck2.c
--- typeck2.c   1 Aug 2005 04:02:26 -0000       1.192
+++ typeck2.c   2 Oct 2005 03:36:41 -0000
@@ -613,10 +613,13 @@ store_init_value (tree decl, tree init)
   value = digest_init (type, init);
   /* If the initializer is not a constant, fill in DECL_INITIAL with
      the bits that are constant, and then return an expression that
-     will perform the dynamic initialization.  */
+     will perform the dynamic initialization.  We don't have to do this
+     for local variables either.  */
   if (value != error_mark_node
       && (TREE_SIDE_EFFECTS (value)
-          || ! initializer_constant_valid_p (value, TREE_TYPE (value))))
+          || ! initializer_constant_valid_p (value, TREE_TYPE (value)))
+      && (TREE_CODE (decl) != VAR_DECL
+          || TREE_STATIC (dest)))
     return split_nonconstant_init (decl, value);
   /* If the value is a constant, just put it in DECL_INITIAL.  If DECL
      is an automatic variable, the middle end will turn this into a


Thanks. The last line of this patch should use "decl", not "dest". With that obvious change it tests OK in apple's branch. (I cannot build mainline on darwin
x86 at the moment for unrelated reasons - nothing that means there is
a problem in mainline, I don't think.)

Reply via email to