Paul Richard Thomas wrote:
*************** gfc_alloc_allocatable_for_assignment (gf
*** 8224,8229 ****
--- 8250,8262 ----
desc, tmp);
tmp = gfc_conv_descriptor_dtype (desc);
gfc_add_modify (&alloc_block, tmp, gfc_get_dtype (TREE_TYPE (desc)));
+ if ((expr1->ts.type == BT_DERIVED)
+ && expr1->ts.u.derived->attr.alloc_comp)
+ {
+ tmp = gfc_nullify_alloc_comp (expr1->ts.u.derived, desc,
+ expr1->rank);
+ gfc_add_expr_to_block (&alloc_block, tmp);
+ }
alloc_expr = gfc_finish_block (&alloc_block);
When glancing at the patch, I wondered whether it would be better to use
CALLOC instead of MALLOC and avoid the nullification:
/* Malloc expression. */
gfc_init_block (&alloc_block);
tmp = build_call_expr_loc (input_location,
builtin_decl_explicit (BUILT_IN_MALLOC),
1, size2);
On the other hand, the nullification is probably still required for
REALLOC. If so, the question is whether CALLOC + nullify in the realloc
branch - or malloc + nullify after the realloc/malloc branches is
better. Hence, your version is probably fine.
Sorry for not yet reviewing your patch.
Tobias
PS: Regarding "allocatable" and "memory leak": PR55603 has as similar
issue. For scalars, gfortran never frees allocatable function results;
that's independent of the LHS (allocatable, pointer, neither). Thus, if
you are in the mood of fixing those kind of bugs … (Actually, I am not
even sure whether that's restricted to allocation, it might also occur
with expressions like "a = f() + 5". Untested.)
