>> The following fixes PR63152 zeroing the data field only for allocatables,
>> not pointers. The benefit of the patch is a >small speedup, and it avoids
>> that code starts to rely on behavior that is undefined in the standard. With
>> this patch, >something like
>>
>> INTEGER, DIMENSION(:), POINTER :: foo
>> IF (ASSOCIATED(foo)) ...
>>
>> will be detected by valgrind as undefined behavior.
>
>The code you touch is exercised in four different cases, as far as I can see
>from the assert earlier in the function:
>
> gcc_assert (sym->attr.pointer || sym->attr.allocatable || sym_has_alloc_comp
> || has_finalizer);
>
>So do we want to test (sym->attr.allocatable), or (!sym->attr.pointer)? Or,
>asked another way: should we NULLIFY in the case of sym_has_alloc_comp ||
>has_finalizer?
Hi FX,
thanks for your good question. I think it is equivalent, as it seems that
GFC_DESCRIPTOR_TYPE_P (type) implies either sym->attr.allocatable or
sym->attr.pointer. To check, I rank a check-fortran with the explicit patch
below, and this made no difference. Code gen for a number of additional
testcases involving alloc_comp and finalizers looked good as well. So, I think
the original patch is still fine.
Joost
Index: trans-array.c
===================================================================
--- trans-array.c (revision 215373)
+++ trans-array.c (working copy)
@@ -8647,9 +8647,18 @@ gfc_trans_deferred_array (gfc_symbol * s
type = TREE_TYPE (descriptor);
}
- /* NULLIFY the data pointer. */
+ /* NULLIFY the data pointer, for non-saved allocatables. */
if (GFC_DESCRIPTOR_TYPE_P (type) && !sym->attr.save)
- gfc_conv_descriptor_data_set (&init, descriptor, null_pointer_node);
+ {
+ if (sym->attr.allocatable)
+ {
+ gfc_conv_descriptor_data_set (&init, descriptor, null_pointer_node);
+ }
+ else
+ {
+ if (!sym->attr.pointer) gcc_unreachable ();
+ }
+ }
gfc_restore_backend_locus (&loc);
gfc_init_block (&cleanup);
