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