Re: Patch to decl2.c

[Mark Mitchell <mark at codesourcery dot com>]

On Fri, 2003-09-05 at 10:30, Michael Elizabeth Chastain wrote:
> Mark Mitchell writes:
> > ... and Richard's patch to optimize.c was supposed to handle
> > this problem, if I understand correctly.
> 
> Ummmm, have another look at PR 12161.  Richard's patch fixes
> optimize_inline_calls.  Look at the call stack I attached to PR 12161 --
> there is no optimize_inline_calls on the call stack.  Maybe Richard's
> patch fixes a different case of gc clobberage but it doesn't fix my
> case.
> 
> Also, I did some builds with enable-checking=gc,gcac,blah,blah,everything
> to check.  Richard's patch does not fix the problem on my machine,
> and Geoff's patch does fix the problem.

Well, that's certainly a useful datapoint.

However, this fix is going to hurt compile-times, and it does it not
localize the fix to the affected code, so this bug will almost certainly
be reintroduced.

Presumably, the problem is occurring when instantiate_decl is called in
the /*defer_ok=*/0 case, and instantiate_decl then calls
expand_or_defer_fn.  Either in expand_or_defer_fn itself, or in
instantiate_decl right before and right after the call, is where the
push/pop calls should go.

I suspect that what's going wrong is that we used to bump function_depth
to indicate how much "nesting" was going on, and do push/pop calls when
in the nested context, in genrtl_finish_function.  The Henderson/Merrill
patch got rid of that, if I understand correctly, and that's why we're
having the problems.

The old code was good in that the push/pop calls happened only when
necessary, and the push/pop was local; now, we're pushing/popping much
more than we should, and we've got non-local code to maintain.

The simplest fix may simply be to reintroduce function_depth, and check
it in tree_rest_of_compilation, which is after all just
genrtl_finish_function, with some additional generality.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com