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