Re: PR3256: Exceptions vs. delay slots

[Richard Henderson <rth at redhat dot com>]

On Thu, Jul 19, 2001 at 01:19:52PM -0700, Mark Mitchell wrote:
> PR3256 (a regresion from GCC 2.95.x) contains code that looks roughly
> like:
> 
>   int f() {
>     int i = 1;
> 
>     try {
>       g();
>       i = 2;
>     } catch (...) {
>     }
> 
>     return i;
>   }
> 
> We brilliantly put the assignment `i = 2' into the delay slot of `g'
> on SPARC.  (In the larger test-case, I don't know if this will happen
> for this tiny test-case.)  This is not good because when we get back,
> after `g' throws an exception, `i' has the wrong value.
> 
> The reason we do this is that `i' is `%l2', and that is not a
> call-clobbered register, so we know there is no conflict between the
> call and the set.  We reason "if the function returns, then `i' will
> be set to `2', so we may as well do it now."
> 
> Oops, but exceptions make life interesting; you can get back to the
> same function without returning from the function call.
> 
> I am thinking that we need to change our delay-slot scheduler to not
> pull instructions from beyond calls that might throw exceptions (i.e,
> calls that are not marked `nothrow' when -fexceptions is turned on).

Ideally, we'd notice whether or not the register in question is
actually live in the exception handler.  Except that the CFG is
horked by this time, so we can't actually do that.

So, yes, you should use can_throw_internal to find out if the
call can throw *and* be caught within the current function.


r~