**ping**
On 23 January 2013 11:06, Tobias Burnus <bur...@net-b.de> wrote:
> 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.)
--
The knack of flying is learning how to throw yourself at the ground and miss.
--Hitchhikers Guide to the Galaxy
