[Patch, fortran] PR56008 (and PR47517) [F03] wrong code with lhs-realloc on assignment with derived types having allocatable components

[Tobias Burnus]

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