This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[tree-ssa] Fun with exceptions -- opinions needed
- From: law at redhat dot com
- To: gcc at gcc dot gnu dot org
- Date: Fri, 13 Jun 2003 17:47:17 -0600
- Subject: [tree-ssa] Fun with exceptions -- opinions needed
- Reply-to: law at redhat dot com
So, who can spot the bug in this code fragment (.cfg dump):
i = 0;
try
{
# BLOCK 1 (j.C:68). PRED: 0. SUCC: 6 2.
{
strm.4 = &strm;
strm.5 = (struct basic_istream<char,std::char_traits<char> >
*)strm.4;
i = get (strm.5)
}
}
catch
{
# BLOCK 2 (j.C:71). PRED: 1. SUCC: 3.
catch (struct foobar)
{
# BLOCK 3 (j.C:71). PRED: 2. SUCC: 4.
{
struct foobar <UV7540>;
<UV77e0> = __cxa_begin_catch (<<<exception object>>>);
try
{
# BLOCK 4 (j.C:71). PRED: 3. SUCC: 5 6.
T.6 = (struct foobar &)<UV77e0>;
<UV7540> = *T.6;
{
(void)0
}
}
finally
{
# BLOCK 5 (j.C:71). PRED: 4. SUCC: 6.
__cxa_end_catch ()
}
}
}
};
# BLOCK 6 (j.C:73). PRED: 5 4 1. SUCC: 8 7.
{
if (i != 0)
Hint it involves exceptions and the variable "i".
OK. So think about what happens if "get" throws an exception in
the statement "i = get (strm.5)". Right, the side effect of assigning
a new value to "i" does not happen.
I'm not real hot on the idea of trying to teach the optimizers about
this little gem. However, the idea of always copying the value through
a temporary isn't all that appealing either, though it appears to be
a lot cleaner.
Thoughts/comments?
Jeff
ps. We don't trigger this bug in tree-ssa right now because the CFG
we build is overly conservative and the extra edges effectively hide
any bugs which result from this issue. However, with the code to
improve cleanups this problem will trigger.