Bug 11545

Summary: [3.4 regression] Segmentation fault when marking cgraph_node in unit-at-a-time mode
Product: gcc Reporter: Steven Bosscher <steven>
Component: middle-endAssignee: Jan Hubicka <jh>
Status: RESOLVED FIXED    
Severity: critical CC: gcc-bugs, snyder
Priority: P1 Keywords: GC, ice-on-valid-code
Version: 3.4.0   
Target Milestone: 3.4.0   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2003-07-16 13:08:04
Bug Depends on:    
Bug Blocks: 8361    
Attachments: smaller testcase
Smaller testcase (12439 down from 16504)
an even smaller testcase (9946 down from 12439)

Description Steven Bosscher 2003-07-16 11:29:28 UTC
The code in question is generate-3.4.ii which is the test case for Bug 8361.

cc1plus -O3 -quiet -fpermissive 8361.ii
In file included from dl.h:165,
                 from generate.C:6:
literal.h: In member function `bool TLITERAL<T>::isSaviour() const':
literal.h:67: warning: there are no arguments to `isBuiltin' that depend on a
   template parameter, so a declaration of `isBuiltin' must be available
literal.h:67: warning: there are no arguments to `isComplexBuiltin' that depend
   on a template parameter, so a declaration of `isComplexBuiltin' must be
   available
literal.h:68: warning: there are no arguments to `isAggregate' that depend on a
   template parameter, so a declaration of `isAggregate' must be available
literal.h:68: warning: there are no arguments to `getAggregate' that depend on
   a template parameter, so a declaration of `getAggregate' must be available
In file included from generate.C:6:
depgraph.h: In member function `void DEPGRAPH<ATOM_TYPE, CONSTRAINTS_TYPE,
   PROGRAM_TYPE>::computeAllComponentConstraints(const CONSTRAINTS_TYPE&)':
depgraph.h:1663: warning: there are no arguments to `SafeExit' that depend on a
   template parameter, so a declaration of `SafeExit' must be available
 
Program received signal SIGSEGV, Segmentation fault.
gt_ggc_mx_cgraph_node (x_p=0x46a95360) at gtype-desc.c:87
87            gt_ggc_m_9tree_node ((*x).decl);
(gdb) p x
$2 = (struct cgraph_node *) 0x0
(gdb) where
#0  gt_ggc_mx_cgraph_node (x_p=0x46a95360) at gtype-desc.c:87
#1  0x0827af49 in gt_ggc_m_P11cgraph_node4htab (x_p=0x413dcf40) at gtype-desc.c:1218
#2  0x08277262 in ggc_mark_roots () at ../../mainline/gcc/ggc-common.c:111
#3  0x083eae84 in ggc_collect () at ../../mainline/gcc/ggc-page.c:1769
#4  0x0840fbe6 in cgraph_finalize_compilation_unit ()
    at ../../mainline/gcc/cgraphunit.c:236
#5  0x080e0945 in finish_file () at ../../mainline/gcc/cp/decl2.c:2938
#6  0x083bb89a in compile_file () at ../../mainline/gcc/toplev.c:1764
#7  0x083c028e in do_compile () at ../../mainline/gcc/toplev.c:4605
#8  0x083c03a5 in toplev_main (argc=1, argv=0x47009438)
    at ../../mainline/gcc/toplev.c:4646
#9  0x400355cd in __libc_start_main () from /lib/libc.so.6

This used to work not so long ago, so this is a regression on the trunk.  Do
other people see this as well?
Comment 1 Andrew Pinski 2003-07-16 13:08:04 UTC
I think this is the same bug as bug 11529.
It references a part of a patch which causes this seg fault.
Comment 2 Andrew Pinski 2003-07-16 13:40:22 UTC
*** Bug 11529 has been marked as a duplicate of this bug. ***
Comment 3 Andrew Pinski 2003-07-16 13:41:56 UTC
From bug 11592:
Doing a regression search, it looks like this problem first appeared
after the big change on Jul 11 from Geoffrey Keating  <geoffk@apple.com>:

2003-07-11  Geoffrey Keating  <geoffk@apple.com>

	* c-decl.c (finish_decl): Handle 'used' here...
	* cgraphunit.c (cgraph_finalize_function): ... and here ...
	* c-common.c: (handle_used_attribute): ... not here.
        ...
        ...

In particular, i found that if i reverted his change to
cgraph.h:

	* cgraph.h (struct cgraph_node): Add chain_next and chain_prev GTY
	options.

then the crash went away.

A simple include of iostream causes this segfault (you have to use "--param ggc-min-
expand=0 --param ggc-min-heapsize=0" which forces gc to happen always).
Comment 4 Andrew Pinski 2003-07-16 15:13:56 UTC
Created attachment 4412 [details]
smaller testcase

run with --param ggc-min-expand=0 --param ggc-min-heapsize=0 -funit-at-a-time
Comment 5 Andrew Pinski 2003-07-16 15:33:06 UTC
Created attachment 4413 [details]
Smaller testcase (12439 down from 16504)

same as before run with  --param ggc-min-expand=0 --param ggc-min-heapsize=0
-funit-at-a-time
Comment 6 Andrew Pinski 2003-07-16 16:04:39 UTC
Created attachment 4414 [details]
an even smaller testcase (9946 down from 12439)

same as before run with --param ggc-min-expand=0 --param ggc-min-heapsize=0
-funit-at-a-time
It does not seems want to go down further.
Comment 7 Andrew Pinski 2003-07-17 15:07:26 UTC
I found a 3 lines testcase which fails (c also, again compile with
--param ggc-min-expand=0 --param ggc-min-heapsize=0 -funit-at-a-time):
static __inline__ void gen_tstsfgt_gpr() {}
static __inline__ void gen_cmpsflt_gpr() {}
void mul_double () {}
Comment 8 Wolfgang Bangerth 2003-07-17 15:11:36 UTC
What an amazing testcase -- with an amazingly complicated callgraph :-)
W.
Comment 9 Andrew Pinski 2003-07-17 15:18:17 UTC
The amazing test case came from fold-const.c (for powerpc64-linux, from around june 
28) (the arguments were removed to reduce it further).
Comment 10 Andrew Pinski 2003-07-17 15:25:38 UTC
The smaller testcase fails on powerpc-apple-darwin6.6 but does not i686-unknown-
openbsd3.1 for some reason, then again there was another one of these gc bugs where 
it did not fail on i686 but it did on i386.
Comment 11 Steven Bosscher 2003-07-18 15:27:30 UTC
Fixed with http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01897.html

Jan,

You commited:

Fri Jul 18 17:03:20 CEST 2003  Jan Hubicka  <jh@suse.cz>

	* cgraph.c (cgraph_remove_node): Clear the hash table slot.

but the proper ChangeLog entry should have been

2003-07-18 17:03:20 CEST 2003  Jan Hubicka  <jh@suse.cz>

	Bug 11545
	* cgraph.c (cgraph_remove_node): Clear the hash table slot.

I.e. ISO dates and mention the number of the related bug report.