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 debug/66688] [6 Regression] compare debug failure building Linux kernel on ppc64le


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66688

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Richard Biener from comment #5)
> > (In reply to Jakub Jelinek from comment #4)
> > > Created attachment 37027 [details]
> > > gcc6-pr66688.patch
> > > 
> > > I think this just went latent with those changes.  The problem I see is that
> > > cleanup_control_flow_bb can be called before fixup_noreturn_call is
> > > performed, and in that case can either find a noreturn call at the end of bb
> > > if -g0 or can't if the noreturn call is followed by some debug stmts.  This
> > > hunk fixes the case so that it is handled the same.
> > 
> > Hum, why not just s/gsi_last_bb/gsi_last_nondebug_bb/?
> 
> That is possible too, but IMHO you still want to remove the debug stmts at
> that point, removing fallthru edge while keeping noreturn call in the middle
> of bb is weird.

True...

> Plus there is the question what to do if the other stmt
> kinds the function is looking for are followed by debug stmts.  I'd strongly
> hope they aren't, so perhaps we can just assert in that case it is the last
> stmt.

Yes, I think for those it cannot happen.

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