This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/66688] [6 Regression] compare debug failure building Linux kernel on ppc64le
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 14 Dec 2015 15:09:50 +0000
- Subject: [Bug debug/66688] [6 Regression] compare debug failure building Linux kernel on ppc64le
- Auto-submitted: auto-generated
- References: <bug-66688-4 at http dot gcc dot gnu dot org/bugzilla/>
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.