Here is the revised patch. Bootstrap and regression tested on linux/x86-64.
Honza, can you comment on the implication of this change?
thanks,
David
On Mon, Nov 7, 2011 at 2:09 PM, Richard Guenther
<richard.guent...@gmail.com> wrote:
> 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.
>
Index: cgraphunit.c
===================================================================
--- cgraphunit.c (revision 181013)
+++ cgraphunit.c (working copy)
@@ -332,7 +332,7 @@ cgraph_lower_function (struct cgraph_nod
a new GC context, or just not compile right now. */
void
-cgraph_finalize_function (tree decl, bool nested)
+cgraph_finalize_function (tree decl, bool nested ATTRIBUTE_UNUSED)
{
struct cgraph_node *node = cgraph_get_create_node (decl);
@@ -371,9 +371,6 @@ cgraph_finalize_function (tree decl, boo
/* Possibly warn about unused parameters. */
if (warn_unused_parameter)
do_warn_unused_parameter (decl);
-
- if (!nested)
- ggc_collect ();
}
/* C99 extern inline keywords allow changing of declaration after function
