RE: Exception handling problem: return address dead

["Boehm, Hans" <hans_boehm at hp dot com>]

Thanks.  I looked at this a bit more in light of your explanation.  It
actually looks like everything is correct up to the scheduling phase.  All
possible RTL dumps look correct.  The problem in the scheduler seems to be
roughly that I start with:

<stuff 1>
r36 = b0
<stuff 2>
conditional branch to L1
<code that returns normally>
L1:
<code that always raises an exception. Without my patch r36 is dead here>

Since r36 is dead if the branch is taken, the scheduler appears to decide
that it's OK to move the save of b0 to below the branch.  As far as I can
tell, this is correct based on the information it currently has.  But it
breaks the unwinder.  Thus I still think we need a way to ensure that r36 is
live wherever an exception might be raised.  I assume that non-call
exceptions sites are always viewed as possibly finishing normally, so it
should suffice to handle call sites.

My example is a 20 line function extracted from code in SPECjbb that was
contributed by Sun.  I'm not sure whether I can legally post it or send it
to a non-SPEC-licensee.  Otherwise I would.

Hans

> -----Original Message-----
> From: Richard Henderson [mailto:rth@redhat.com]
> Sent: Tuesday, November 20, 2001 2:19 PM
> To: Boehm, Hans
> Cc: 'gcc@gcc.gnu.org'
> Subject: Re: Exception handling problem: return address dead
> 
> 
> On Tue, Nov 20, 2001 at 11:35:40AM -0800, Boehm, Hans wrote:
> > One reason stack unwinding on Itanium still fails 
> occasionally is that the
> > gcc back end occasionally decides that the return address 
> is dead at program
> > points at which it's guaranteed that an exception will be 
> raised.  This
> > subsequently makes it impossible to unwind the stack.
> 
> This was supposed to be handled by 
> 
>           /* Even if we're not going to generate an epilogue, we still
>              need to save the register so that EH works.  */
>           if (! epilogue_p)
>             emit_insn (gen_rtx_USE (VOIDmode, alt_reg));
> 
> What's getting in the way here?  -frename-registers?
> 
> 
> r~
>