https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921
--- Comment #23 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 28 Jul 2015, mikael at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64921 > > --- Comment #22 from Mikael Morin <mikael at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #21) > > Transfer.4 _is_ null in the case we segfault. So the guard us clearly > > wrong. > > > OK, let's try something else. > Are you positive transfer.4 is null? > I don't see anything that would make it so. >From inspecting registers and the assembly. The debugger cannot get at the artificial decls. > If it is transfer.10 that is null, I can see the call to __final_main_T2 that > is suspicious; it seems to pass a descriptorless array to an argument > expecting > a descriptor. > > Draft patch, seems to fix it > > diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c > index 218973d..7a9e275 100644 > --- a/gcc/fortran/class.c > +++ b/gcc/fortran/class.c > @@ -1599,6 +1599,7 @@ generate_finalization_wrapper (gfc_symbol *derived, > gfc_namespace *ns, > final->ts.type = BT_INTEGER; > final->ts.kind = 4; > final->attr.artificial = 1; > + final->attr.always_explicit = 1; > final->attr.if_source = expr_null_wrapper ? IFSRC_IFBODY : IFSRC_DECL; > if (ns->proc_name->attr.flavor == FL_MODULE) > final->module = ns->proc_name->name; even better