Hi Harald, Thanks for your comment. I am looking into the reason why I alighted on that condition. My notes don't recall the reason. I'll clean up/fix, as necessary before pushing and will post the final version of the patch.
BTW Happy New Year to you! Paul On Mon, 5 Jan 2026 at 20:57, Harald Anlauf <[email protected]> wrote: > Am 05.01.26 um 9:51 PM schrieb Jerry D: > > On 1/5/26 8:30 AM, Paul Richard Thomas wrote: > >> Hi All, > >> > >> This PR was largely fixed by preceding patches, insofar as it ran and > >> produced the expected output, apart from the explicit initialization > >> expressions for the PDT entities. However, the testcase leaked memory > >> like a sieve and it has taken a while to sort out a satisfactory fix. > >> > >> The chunks in trans-decl.cc implement the fix for the explicit > >> initialization of PDT entities. This part is straightforward. > >> > >> The rest of the patch is devoted to fixing the memory leaks triggered > >> by the new testcase. The problem was associated with pdt_arrays > >> embedded in PDT structure constructors, which themselves were embedded > >> in array constructors that were part of a PDT constructor.... if you > >> see what I mean :-) The original pdt_arrays are copied into a > >> destination array, which is implicitly allocated > >> by gfc_duplicate_allocatable. The allocated memory was being lost in > >> the subsequent copy of the enclosing array constructor. Rescuing and > >> freeing the memory is accomplished using the finalization block, which > >> is then executed after the copy of the array constructor. Note that > >> these frees are not guarded. I don't believe that there is any > >> circumstance where this will be an issue but, if required, it would be > >> easily implemented. > >> > >> The chunks in trans-stmt.cc pick up memory leaks in allocation and > >> deallocation. As a side effect, the leak in pdt_3.f03 is fixed. > >> PR121972 will be updated accordingly, since pdt_39/70/77.f03 still > >> leak memory. > >> > >> Regtests on FC43/x86_64. OK for mainline > >> > >> Paul > >> > > > > Looks Good To Me Paul, also regression tested OK here. > > > > Jerry > > > > I wanted to says that I am also fine with the patch, > but have a minor question: > > +static tree > +gfc_init_default_pdt (gfc_symbol *sym, bool dealloc) > { > - /* Allowed in the case where all the components have initializers and > - there are no LEN components. */ > - if (sym->ts.type == BT_DERIVED && sym->ts.u.derived->attr.pdt_type) > + stmtblock_t block; > + tree tmp; > + gfc_component *c; > + > + if (sym->value && sym->value->symtree > + && sym->value->symtree->n.sym > + && !sym->value->symtree->n.sym->attr.artificial) > > Don't you want to check that sym->value is really a variable > before testing symtree? I.e., > > if (sym->value && sym->value->expr_type == EXPR_VARIABLE > && sym->value->symtree > ... > > Thanks, > Harald > > > >
