Ping: https://gcc.gnu.org/ml/fortran/2015-06/msg00075.html

Le 21/06/2015 11:48, Mikael Morin a écrit :
> Le 16/05/2015 18:43, Mikael Morin a écrit :
>> Hello,
>>
>> this is about PR61831 where in code like:
>>      
>>      type :: string_t
>>         character(LEN=1), dimension(:), allocatable :: chars
>>      end type string_t
>>      type(string_t) :: prt_in
>>      (...)
>>      tmp = new_prt_spec ([prt_in])
>>      
>> the deallocation of the argument's allocatable components after the
>> procedure call (to new_prt_spec) has the side effect of freeing prt_in's
>> allocatable components, as the array constructor temporary for [prt_in]
>> is a shallow copy of prt_in.
>>
>> This bug is a regression caused by the Dominique's PR41936 memory leak
>> fix, itself based on a patch originally from me.
>>
>> The attached patch is basically a revert of that fix.  It avoids the
>> problem by not deallocating allocatable components in the problematic
>> case, at the price of a (possible) memory leak.  A new function is
>> introduced telling whether there is aliasing, so that we don't regress
>> on PR41936's memory leak when there is no aliasing, and we don't free
>> components when there is aliasing.
>> The possible remaining memory leak case is the case of a "mixed" array
>> constructor with some parts aliasing variables, and some non-aliasing parts.
>>
>> The patch takes also the opportunity to reassemble the scattered
>> procedure argument deallocation code into a single place.
>>
>> The test needs pr65792's fix (thanks Paul), so for the 4.9 branch I
>> propose commenting the parts that depend on PR65792 in the test.
>>
>> Regression tested on x86_64-linux. OK for 6/5/4.9 ?
> 
> Hello,
> 
> I would like to come back to the patch:
> https://gcc.gnu.org/ml/gcc-patches/2015-05/msg01491.html
> 
> PR66082 made me notice one bug in that patch:
> for descriptorless arrays, the patch was deallocating only the first
> element's allocatable components.
> As gfc_conv_array_parameter returns the array data only, the bounds are
> lost and it is not possible to loop through all the elements.
> 
> With the attached patch, the deallocation code is kept in
> gfc_conv_array_parameter where the bounds of descriptorless arrays are
> known.
> To test this fixes the bug, I have added a count of while (1) loops in
> the dump of pr66082's test.  I'm open to better ideas to properly test this.
> 
> For arrays with descriptors, I have decided to not handle them in
> gfc_conv_array_parameter, because in some cases gfc_conv_expr_descriptor
> is called directly from gfc_conv_procedure_call, without passing through
> gfc_conv_array_parameter.
> To be able to select everything but descriptorless arrays for
> allocatable component deallocation, the flags are moved around somewhat.
> The rest is as in the previous patch.
> 
> The test provided is basically unchanged, thus not suitable for the
> branches without pr65792.
> We can decide what to do with it later (backport pr65792 or disable
> parts of the test), I would like to have the fix in mainline first.
> It has been fortran-tested on x86_64-linux, OK for trunk?
> 
> Mikael
> 
> 
> 

Reply via email to