[Bug other/17437] [4.0 Regression] obscure GC problem

["dnovillo at redhat dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From dnovillo at redhat dot com  2004-09-14 19:07 -------
Subject: Re:  [4.0 Regression] obscure GC problem

On Tue, 2004-09-14 at 11:31, Jeffrey A Law wrote:

> What doesn't make sense to me is that the dataflow information isn't
> attached to SSA_NAMEs, it's attached to statement nodes and PHIs.
> So at least that part of my analysis is faulty.
> 
Because SSA_NAMEs store their defining statement in tree.common.chain
and gt_ggc_mx_lang_tree_node jumps from the SSA_NAME into its defining
statement.  From there, we start traversing the statement's DU chains
and end up in a statement whose basic block has been ggc_free'd already
by cfg.c:expunge_block.

This allows me to go past this failure and go into stage3, but I think
the real issue may be that somebody is holding on to DU chains too long.

I don't know what the right approach would be here.  Force people to
always flush out DU chains?  Maybe.  But then, why put these things on
GC memory to begin with?


Diego.

Index: cfg.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cfg.c,v
retrieving revision 1.65
diff -d -u -p -r1.65 cfg.c
--- cfg.c       7 Sep 2004 15:46:46 -0000       1.65
+++ cfg.c       14 Sep 2004 19:03:02 -0000
@@ -266,7 +266,6 @@ expunge_block (basic_block b)
   unlink_block (b);
   BASIC_BLOCK (b->index) = NULL;
   n_basic_blocks--;
-  ggc_free (b);
 }

 /* Create an edge connecting SRC and DEST with flags FLAGS.  Return newly




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17437