This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

PR3256: Exceptions vs. delay slots


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).
Obviously, you could pull instructions if they only affect things that
will go out of scope before the `catch', etc., etc., but first things
first.

Any objections?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]