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.
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;
