Re: [C++ PATCH] Fix finish_function recursion (PR c++/37189)

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Sep 03, 2008 at 10:21:45AM -0400, Jason Merrill wrote:
> Jakub Jelinek wrote:
> >The problem is that the discovery of OpenMP implicitly determined variables
> >is done at gimplification time.  If a variable is implicitly determined
> >as firstprivate and it has a class type, we need its copy ctor and dtor, 
> >but
> >it is possible it needs to be synthetized.  This leads to calling
> >cp_genericize while in the gimplifier for another function, which is fatal.
> 
> I don't see why that needs to be fatal.  It looks like we already have 
> the code to handle saving outer context, just need to take out the assert.

I'm afraid there are many issues with it, not just one assert.  Of course
we can drop the 2 asserts from gimplify_body and instead save/restore
gimplify_ctxp around.  But finish_function also clobbers
current_function_decl, recursion will break completely the function_depth
counting, zap cfun, and I certainly miss many other global variables.
I don't think the gimplifier is prepared to handle more functions at the
same time.

> >So this patch instead will defer all mark_used calls encountered during 
> >finish_function
> >call until the end of that function.
> 
> This would mean that we can't inline these synthesized [cd]tors.

Why?  We clearly inline it on the testcase given.  finish_function just
gimplifies the function, it doesn't call any further passes.  That's
done far later, driven from cgraph_finalize_compilation_unit and
cgraph_optimize, even early inlining happens later.

	Jakub