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. >> ---