Re: [PATCH] PR125535 wrong-code for implied-do with allocatable-component, derived type and transformational intrinsic

Jerry D <[email protected]> Sun, 7 Jun 2026 12:11:37 -0700
Newsgroups gmane.comp.gcc.patches,gmane.comp.gcc.fortran
Message-ID <[email protected]>
On 6/7/26 6:13 AM, Paul Richard Thomas wrote:
> Hello Jerry,
> 
> This patch looks good to me for mainline and gcc-16.
> 
> However, in common with other test cases with nested array and
> structure constructors, it leaks memory allocated at line 17 of the
> testcase. This is something that we will have to work on because it
> blocks the PDT meta-bug, for example.
> 
> Please apply it as it is but it should be flagged up as a leaker
> (another meta-bug?)
> 

Thanks Paul, I will push this. How many leakers have you identified?

Jerry


> Thanks
> 
> Paul
> 
> On Sat, 6 Jun 2026 at 02:48, Jerry D <[email protected]> wrote:
>>
>> See attached patch.
>>
>> This one is fairly simple. This is also the last of the meta-bug PR125515.
>>
>> Regression tested on x86_64.
>>
>> I will probably simplify the commit message. Thought I should comments before I
>> do that.
>>
>> OK for mainline and later backport to 16.
>>
>> Regards,
>>
>> Jerry
>>
>> ---
>>
>>
>> When a nested implied-do array constructor called a transformational
>> intrinsic (e.g. RESHAPE) whose result type has allocatable components, the
>> argument temporaries were freed before the result's allocatable components
>> were deep-copied, causing a heap-use-after-free and wrong runtime values.
>>
>> The root cause: in gfc_conv_procedure_call, the call to
>> gfc_add_block_to_block (&se->pre, &post) — which frees the allocatable
>> components of argument temporaries — was issued before the deep-copy loop
>> for the result's allocatable components.  Transformational library functions
>> such as RESHAPE do a shallow byte-copy of the source array into the result,
>> so the result's component pointers alias those of the argument temporaries.
>> Freeing the temporaries first and then copying yielded use-after-free.
>>
>> Fix: move gfc_add_block_to_block (&se->pre, &post) to after the deep-copy
>> loop, so that the result's allocatable components are copied while the
>> source storage is still live.
>>
>> PR fortran/125535
>>
>> Assisted by: Claude Sonnet 4.6
>>
>> gcc/fortran/ChangeLog:
>>
>>          PR fortran/125535
>>          * trans-expr.cc (gfc_conv_procedure_call): Move post block append
>>          to after the deep copy of allocatable components for transformational
>>          intrinsics, so that argument temporaries are not freed before the
>>          result components are copied.
>>
>> gcc/testsuite/ChangeLog:
>>
>>          PR fortran/125535
>>          * gfortran.dg/implied_do_alloc_comp_1.f90: New test.
>> ---