This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 07 Oct 2011 18:59:26 +0000
- Subject: [Bug middle-end/50640] [4.7 Regression] FAIL: gfortran.dg/select_type_12.f03 -O (internal compiler error)
- Auto-submitted: auto-generated
- References: <bug-50640-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50640
--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-07 18:59:26 UTC ---
(In reply to comment #6)
> (In reply to comment #3)
> > 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).
>
> Huh, I don't see why tree-ssa-live would need to walk variable initializers
> (which generally don't exist unless for static storage duration vars).
Possibly for
void foo (void)
{
static int i;
static int *p = &i;
return *p;
}
to make i used and thus retained in BLOCK_VARS and thus debuginfo.