http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #3 from Michael Matz <matz at gcc dot gnu.org> 2011-10-07 16:45:55 UTC --- Hmm, this is not as trivial as PR50638. fortran frontend generates this static variable local to MAIN: static struct __vtype_MAIN___T1 __vtab_MAIN___T1 = {._hash=41707971, ._size=4, ._extends=0B, ._def_init=&__def_init_MAIN___T1, ._copy=__copy_MAIN___T1}; (the reference to &__def_init_MAIN___T1 will later cause the segfault). __vtab_MAIN___T1 will be referenced from __vtab_MAIN___T2 (also static local in MAIN). But __vtab_MAIN___T2 will _not_ be referenced from MAIN. Instead references to __vtab_MAIN___T2 and __vtab_MAIN___T1 are emitted from function 'fun'. So far so good. The problem lies in walking DECL_INITIAL for these statics. add_referenced_var will only walk it if DECL_CONTEXT==current_function_decl (sensible). Nobody calls add_rerefenced_var(__vtab_MAIN___T1) for function MAIN (sensible, as there are no references). We will call add_rerefenced_var(__vtab_MAIN___T1) from function 'fun' (also sane), which then won't walk DECL_INITIAL, i.e. nobody makes __def_init_MAIN___T1 referenced. The the code in tree-ssa-live comes and walks initializers of local variables that are used. It does so for function MAIN and variable __vtab_MAIN___T (which is in local_decls, just not in referenced_vars), because it is marked used (it's a non-local decl, therefore var_ann is still active from the calls from function 'fun'). That one then walks the initializer and now notices that nothing in it is marked referenced. The non-triviality here lies in deciding who's wrong: add_referenced_var (i.e. should it always mark referenced all initializers, even though they might come from other function contexts), the tree-ssa-live code (should it perhaps not look into initializers or at least expect them not necessarily marked), or in the fortran frontend (should it perhaps call add_referenced_var also for the local static in MAIN).