This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question on GIMPLE semantics and EH
- From: Richard Henderson <rth at redhat dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: amacleod at redhat dot com, gcc at gcc dot gnu dot org
- Date: Fri, 13 Aug 2004 11:12:36 -0700
- Subject: Re: Question on GIMPLE semantics and EH
- References: <10408131234.AA13898@vlsi1.ultra.nyu.edu>
On Fri, Aug 13, 2004 at 08:34:51AM -0400, Richard Kenner wrote:
> Suppose I have something like:
>
> foo = 0;
> ...
> foo = some_function_call_that_may_throw ( ...);
>
> in one basic block and then in the exception handler, we have:
>
> bar = foo;
>
> As I understand it, the semantics of GIMPLE is that the second assignment to
> FOO may not happen, but if it doesn't, then the value must remain 0.
Not exactly. It depends on the type of foo. From the assignment
from zero, I assume it's scalar. Which means that the value always
dies at the function call. Which is why you should *not* have seen
an assignment to foo directly out of the .10.gimple dump -- it should
have been a temporary.
I presume the temporary name got folded away by the first copyrename
pass, but that in the dump you're looking at, the two occurrences of
foo have different ssa names.
> copyrename2 is replacing the second assignment's LHS with BAR.
No. It's replacing the base of the SSA_NAME, which is absolutely
not the same thing.
Do not drop ssa names from problems you report. It only confuses
the issue.
> What's going wrong here?
Who knows. Give us a proper bug report and we might be able to help.
r~