This is the mail archive of the
gcc-patches@gcc.gnu.org
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: <18986.43617.466045.279657@ropi.home> <84fc9c000906080603n145b6bc6i90e180be312296e5@mail.gmail.com>
- 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<anemet@caviumnetworks.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?
>
> 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:
In
/* Look for both regular and sibcalls to end the block. */
if (returnjump_p (i))
break;
if (CALL_P (i) && SIBLING_CALL_P (i))
break;
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.
Jakub