This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix -fcompare-debug failure during inlining (PR tree-optimization/44182)
On Mon, 31 May 2010, Jakub Jelinek wrote:
> On Mon, May 31, 2010 at 11:05:50AM +0200, Richard Guenther wrote:
> > > --- gcc/tree-inline.c.jj 2010-05-28 00:07:09.000000000 +0200
> > > +++ gcc/tree-inline.c 2010-05-31 09:01:17.000000000 +0200
> > > @@ -1836,7 +1836,7 @@ update_ssa_across_abnormal_edges (basic_
> > > accordingly. Edges will be taken care of later. Assume aux
> > > pointers to point to the copies of each BB. */
> > >
> > > -static void
> > > +static bool
> >
> > Please adjust the comment for the changed interface.
>
> Okay.
> >
> > I suppose that before fixup-cfg is run there will be no EH edges
> > for the now throwing stmt, right?
>
> copy_edges_for_bb is creating them.
Ok, then indeed ...
> > If you are re-setting debug stmts that would be moved into a block
> > with multiple predecessors then why not, for simplicity, always
> > reset debug stmts even if you'd now had multiple successors for
> > new_bb so you can simply move debug stmts instead of re-creating
> > them and playing games with copy_debug_stmts?
>
> I don't understand how can I just move them. The bb has at least two
> successors, it is not sufficient to have the debug stmts just in one of the
> successors.
... you have at least two succs.
> Dropping them on the floor is not a good option either, consider
> DEBUG j => 6
> foo (); # which got a new EH edge now.
> DEBUG j => 8
> goto bbX;
> If DEBUG j => 8 is dropped, then the debugger will think j is 6
> in bbX or in the EH pad, while it is 8 there.
> If you just move debug stmts to bbX:, then the debug info is wrong
> in the EH pad.
But you could move them to the last succ instead of copying them
there. Btw - do debug stmts have a location? If so you probably
want to copy those too.
Richard.