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: [PATCH] Fix PR45874


On Wed, 13 Oct 2010, Martin Jambor wrote:

> On Wed, Oct 13, 2010 at 12:04:48PM +0200, Richard Guenther wrote:
> > 
> > This fixes PR45874 - we need to fixup the CFG when gsi_replace
> > fixes up EH.  This does it the proper way manually.
> > 
> > Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
> > 
> > Richard.
> > 
> > 2010-10-13  Richard Guenther  <rguenther@suse.de>
> > 
> > 	PR middle-end/45874
> > 	* cgraphunit.c (cgraph_redirect_edge_call_stmt_to_callee):
> > 	Fixup the CFG when EH was fixed up.
> > 
> 
> Isn't it necessary to return TODO_cleanup_cfg from the pass that does
> this?  If so, we either need to communicate that we have changed the
> statement to inline_transform or return TODO_cleanup_cfg from there
> unconditionally (which I think would be acceptable in this particular
> function).  Or is it somehow not necessary?

It is not necessary in case dominator information is available as then
EH edge removal also removes unreachable blocks.

But yes, the flow of code here isn't 100% clear to me either (for example
why do we have a fixup_cfg pass at all, and which passes are allowed
to keep things non-updated).

An alternative fix, delaying things to an eventually run fixup_cfg
would have just passed false to gsi_replace.  But I don't like
fixup_cfg in the first place.

(as of how we run cleanup-cfg - I think it would be much nicer to
maintain a property in the pass manager which we could clear anywhere
and that would trigger cfgcleanup)

So - basically I'm waiting for a new testcase that now breaks ;)

Richard.


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