Le 04/07/2023 à 21:00, Harald Anlauf a écrit :
Hi Mikael, all,
I think I've found it: there is a call to gfc_conv_class_to_class
that - according to a comment - does a repackaging to a class array.
Deferring that repackaging along with the deallocation not only fixes
the regression, but also the cases I tested.
Attached is a "sneak preview", hoping that the experts (Paul, Mikael,
...) can tell if I am going down the wrong road.
I think that's it mostly. There is one last thing that I am not sure...
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 16e8f037cfc..a68c8d33acc 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6858,6 +6860,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
&& e->symtree->n.sym->attr.optional,
CLASS_DATA (fsym)->attr.class_pointer
|| CLASS_DATA (fsym)->attr.allocatable);
+
+ /* Defer repackaging after deallocation. */
+ if (defer_repackage)
+ gfc_add_block_to_block (&dealloc_blk, &parmse.pre);
}
else
{
... whether you will not be deferring too much here. That is parmse.pre
contains both the argument evaluation and the class container setup from
gfc_conv_class_to_class. If it's safe to defer both, that's fine,
otherwise a separate gfc_se struct should be passed to
gfc_conv_class_to_class so that only the latter part can be deferred.
Need to think of an example...
