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] Obvious change in compute_dominance_frontiers


> Hello,
> 
> > Can we add an abort or something for the case where
> > ENTRY_BLOCK_PTR->succ->succ_next is not NULL?  We may not gracefully
> > handle multiple entry points in many places yet, but it will make them a
> > lot easier to track down when we do need to handle them.
> 
> note that there are hundreds of places in gcc that assume that
> ENTRY_BLOCK_PTR->succ->succ_next == NULL; so taking care of this one
> would be a little help.  And IIRC multiple entry points are already
> handled by different means.

Multiple entry points are supposed to work like this (having multiple
succ edges of ENTRY_BLOCK_PTR) but they are currently completely broken,
this is one of reasons why :)
Why the code can't use simply ENTRY_BLOCK_PTR as starter of walk?  It
seems to me like artefact from array based datastructure for dominators.

Honza
> 
> Zdenek


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