This is the mail archive of the gcc-patches@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]

Re: [tree-ssa] Allow next field to point to the same field


In message <20031202220036.GH25126@atrey.karlin.mff.cuni.cz>, Jan Hubicka write
s:
 >But perhaps still it may make sense to consider the patch so we won't
 >run into this interesting trap again.
But if it's a situation that fundamentally shouldn't happen, then I'd
prefer not to hack up the GC/GT system to deal with it.  Every change
we make has the potential for bugs, so why make a change that is not
necessary.

 >I saw it when there has been dead annotations kept after de-ssa pass, so
 >I would assume that de-SSA pass uses this field some bookkeeping. 
Nope, to the best of my knowledge out-of-ssa doesn't modify that field
at all -- it uses its contents to know if a variable might be live at
the start of the function, but the contents are not modified.

In fact, the only two places that field is modified is in
tree-phinodes.c when we create PHI_NODEs (for the result of the
PHI node) and tree-ssanames when we create SSA_NAMEs.

 > If
 >this looks important, I can try to simply remove the code to properly
 >kill annotations and try to reproduce this aagain.
I would suspect the reason you saw this was because we had nodes which
should have been reachable by the GC system, but which were not reachable.
Those nodes got re-used by the GC system, but still could have been on
the SSA_NAMEs or PHI_NODEs freelists due to the bugs in not having everything
registered that should have been registered.

jeff


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