This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
PR3256: Exceptions vs. delay slots
- To: gcc at gcc dot gnu dot org
- Subject: PR3256: Exceptions vs. delay slots
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Thu, 19 Jul 2001 13:19:52 -0700
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