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

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

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

On Tue, 2004-09-14 at 13:07, Diego Novillo wrote:
> 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.
Which is part of the reason why I think sprinkling ggc_free calls
around is generally a bad idea.  While we may think we know the
lifetime of some object, it's bloody easy to miss some pointer
pointing into the object keeping it live.


> 
> 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.
Agreed.

> 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?
Well, IMHO the ggc_free is bogus and we need to fix whatever code
forgot to call free_df.

jeff




-- 


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