This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

On Tue, 2004-09-14 at 13:07, dnovillo at redhat dot com wrote:
> ------- 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?
BTW, I have a theory why this is happening (dangling dataflow
information).

The code to remove dataflow walks through the IL removing dataflow
information on every statement it finds.


So imagine if we had dataflow information attached to a statement
which we delete.   Furthermore, assume that statement is in a
block which we ultimately delete.  ANd (of course) we're assuming
that the statement with the attached dataflow information has a
SSA_NAME in the SSA_NAME table, but assume the SSA_NAME hasn't
been released.


I _think_ that could lead to the behavior we're seeing and would
match the preliminary stuff I've seen under GDB.

jeff




-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]