Hi Paul,
On 29.01.21 15:20, Paul Richard Thomas via Fortran wrote:
Regtests on FC33/x86_64
OK for master (and maybe for 10-branch?)
The patch by itself looks good to me, but
gfortran-trunk assumed_rank_20.f90 -fsanitize=address,undefined -g
shows three times the warning:
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x7f2d5ef6e517 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.6+0xb0517)
#1 0x404221 in __mod_MOD_get_tuple /dev/shm/assumed_rank_20.f90:60
#2 0x40ad8e in alloc_rank /dev/shm/assumed_rank_20.f90:78 (+ line 84, +
line 90)
#3 0x40d9e7 in main /dev/shm/assumed_rank_20.f90:67
Thus, the function-result temporary does not seem to get deallocated
when a constructor is used:
78: output = sel_rank1([get_tuple(x)]) ! This worked OK
84: output = sel_rank2([get_tuple(x)]) ! This worked OK
90: output = sel_rank3([get_tuple(x)]) ! runtime: segmentation fault
Thanks,
Tobias
Fortran: Fix memory problems with assumed rank formal args [PR98342].
2021-01-29 Paul Thomas <pa...@gcc.gnu.org>
gcc/fortran
PR fortran/98342
* trans-expr.c (gfc_conv_derived_to_class): Add optional arg.
'derived_array' to hold the fixed, parmse expr in the case of
assumed rank formal arguments. Deal with optional arguments.
(gfc_conv_procedure_call): Null 'derived' array for each actual
argument. Add its address to the call to gfc_conv_derived_to_
class. Access the 'data' field of scalar descriptors before
deallocating allocatable components. Also strip NOPs before the
calls to gfc_deallocate_alloc_comp. Use 'derived' array as the
input to gfc_deallocate_alloc_comp if it is available.
* trans.h : Include the optional argument 'derived_array' to
the prototype of gfc_conv_derived_to_class. The default value
is NULL_TREE.
gcc/testsuite/
PR fortran/98342
* gfortran.dg/assumed_rank_20.f90 : New test.
-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander
Walter
