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




Reply via email to