On Mon, Nov 7, 2011 at 5:41 PM, Xinliang David Li <davi...@google.com> wrote: > Here is the stack trace when the watch point is hit (the watch point > is on address &cleanups->base.prefix.num > > David > > #0 memset () at ../sysdeps/x86_64/memset.S:336 > #1 0x0000000000d1528d in poison_pages () at > /usr/local/google/davidxl/dev/gcc/tot/gcc/ggc-page.c:1983 > #2 0x0000000000d15424 in ggc_collect () at > /usr/local/google/davidxl/dev/gcc/tot/gcc/ggc-page.c:2076 > #3 0x0000000001028d7f in cgraph_finalize_function > (decl=0x7ffff577d600, nested=0 '\000') at > /usr/local/google/davidxl/dev/gcc/tot/gcc/cgraphunit.c:376
Hm. We already conditionally arrange for cgraph_finalize_function to not call ggc_collect - so it seems that doing so is even less safe than originally thought. Which means I think we should push calling ggc_collect to the callers, which for the C++ frontend means ... > #4 0x0000000000988010 in expand_or_defer_fn (fn=0x7ffff577d600) at > /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/semantics.c:3797 > #5 0x0000000000a678a7 in maybe_clone_body (fn=0x7ffff5770700) at > /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/optimize.c:426 > #6 0x0000000000987aa3 in expand_or_defer_fn_1 (fn=0x7ffff5770700) at > /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/semantics.c:3722 > #7 0x0000000000987fe0 in expand_or_defer_fn (fn=0x7ffff5770700) at > /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/semantics.c:3792 > #8 0x000000000091c5f5 in synthesize_method (fndecl=0x7ffff5770700) at > /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/method.c:773 > #9 0x0000000000551fa0 in cp_finish_decl (decl=0x7ffff5770700, > init=0x7ffff6d8f898, init_const_expr_p=0 '\000', asmspec_tree=0x0, > flags=11) at /usr/local/google/davidxl/dev/gcc/tot/gcc/cp/decl.c:6286 ... probably here. Though I'd also approve a patch that simply removes the ggc_collect call (and the nested parameter). Honza - you probably added the ggc_collect - what's the reason to do it in this lowlevel place? Thanks, Richard.
