This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix ICE with delayed-branch targets after epilogue-unwind patch
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: Adam Nemet <anemet at caviumnetworks dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 15 Jun 2009 17:09:56 +0200
- Subject: Re: [PATCH] Fix ICE with delayed-branch targets after epilogue-unwind patch
- References: <email@example.com> <firstname.lastname@example.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Mon, Jun 08, 2009 at 09:03:10AM -0400, Richard Guenther wrote:
> On Sat, Jun 6, 2009 at 1:41 PM, Adam Nemet<email@example.com> wrote:
> > This fixes the new ICEs in:
> > ?http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00327.html
> > The gcc_assert in dwarf2out_begin_epilogue fires because returnjump_p fails to
> > recognize a return inside a SEQUENCE.
> > Bootstrapped and regtested on mips64octeon-linux.
> > OK?
I'm not convinced this is the right place to fix it.
In most returnjump_p calls SEQUENCEs aren't present at all, and in the
dwarf2out.c case we IMHO have to handle it in the caller anyway:
/* Look for both regular and sibcalls to end the block. */
if (returnjump_p (i))
if (CALL_P (i) && SIBLING_CALL_P (i))
if (RTX_FRAME_RELATED_P (i))
saw_frp = true;
not only the return jump can be inside of SEQUENCE, but so can
be the sibling call and so could be RTX_FRAME_RELATED_P insns.