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: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 13 Aug 04 14:29:35 EDT
- Subject: Re: Question on GIMPLE semantics and EH
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.
OK, that explains it. The type was a scalar (a pointer), but it was a
component of an aggregrate, with the aggregate being the FRAME variable.
So no temporary was used. Then SRA made it into a scalar variable.
Who knows. Give us a proper bug report and we might be able to help.
The test case is the ACATS test c761006, but it's a large mess of
expanded code, so it's hard to read. The function in question is
Adjust_Test and the variable is F36b.
So we have in .t05.nested:
FRAME.178.F36b = 0B;
...
try {
...
FRAME.178.F36b = c761006_2__adj_checkDA (T.200, &another_target, 1);
That's the one that throws.
The "finally" has a call with FRAME.178 as the static chain.
The .t13.lower inlined the second call and has:
T.182 = CHAIN.181->F36b;
system__finalization_implementation__finalize_list (T.182);
The .30.ch has
FRAME.178.F36b = 0B;
...
FRAME.178.F36b = c761006_2__adj_checkDA (0B, &another_target, 1);
...
<bb 40>:
T.182_464 = FRAME.178.F36b;
system__finalization_implementation__finalize_list (T.182_464);
.t32.sra then has:
SR.269_1504 = 0B;
...
SR.269_1505 = c761006_2__adj_checkDA (0B, &another_target, 1);
...
<bb 40>:
T.182_464 = SR.269_1505;
system__finalization_implementation__finalize_list (T.182_464);
which is the case I mentioned and copyrename2 replaces the target of the
call with T.182_1505.