Question on GIMPLE semantics and EH
Richard Kenner
kenner@vlsi1.ultra.nyu.edu
Fri Aug 13 18:29:00 GMT 2004
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.
More information about the Gcc
mailing list