OK.
On Mon, Feb 19, 2018 at 1:56 PM, Jakub Jelinek <ja...@redhat.com> wrote: > Hi! > > While cp_parser_lambda_body which is the other finish_lambda_function > caller next to tsubst_lambda_expr temporarily increments function_depth > around that call (if not nested) to avoid GC during expand_or_defer_fn from > finish_lambda_function, tsubst_lambda_expr doesn't, and on the > lambda-ice14.C we can see the GC in action in that case. > > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for > trunk? > > 2018-02-19 Jakub Jelinek <ja...@redhat.com> > > PR c++/84455 > * pt.c (tsubst_lambda_expr): If not nested, increment temporarily > function_depth to avoid GC during finish_lambda_function. > > * g++.dg/cpp0x/lambda/lambda-ice26.C: New test. > > --- gcc/cp/pt.c.jj 2018-02-16 23:37:29.312364263 +0100 > +++ gcc/cp/pt.c 2018-02-19 10:48:00.328184302 +0100 > @@ -17070,6 +17070,10 @@ tsubst_lambda_expr (tree t, tree args, t > bool nested = cfun; > if (nested) > push_function_context (); > + else > + /* Still increment function_depth so that we don't GC in the > + middle of an expression. */ > + ++function_depth; > > local_specialization_stack s (lss_copy); > > @@ -17084,6 +17088,8 @@ tsubst_lambda_expr (tree t, tree args, t > > if (nested) > pop_function_context (); > + else > + --function_depth; > > /* The capture list was built up in reverse order; fix that now. */ > LAMBDA_EXPR_CAPTURE_LIST (r) > --- gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C.jj 2018-02-19 > 10:51:24.838188732 +0100 > +++ gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice26.C 2018-02-19 > 10:51:19.690188624 +0100 > @@ -0,0 +1,5 @@ > +// PR c++/84455 > +// { dg-do compile { target c++11 } } > +// { dg-options "--param ggc-min-heapsize=0" } > + > +#include "lambda-ice14.C" > > Jakub