Hello Jerry,
Sorry about the missing subject line :-)
Pushed as r17-6009.
Thanks for the previous review and the OK to push.
Of the { dg-run } tests in comment #10 of the PDT meta-bug, only
./pos/p66_N_transfer.f90,
./pos/p67_N_array_intrinsics.f90 and
./reducers/bug20-cshift-double-free.f90
remain to be fixed.
Some of the ./neg/n*.f90 tests do not emit errors when they should and
I have your patch for the bug9 memory leaks/aarch64 issue to test.
Nearly there!
Paul
On Fri, 6 Nov 2026 at 16:18, Jerry D <[email protected]> wrote:
>
> On 11/5/26 9:16 AM, Paul Richard Thomas wrote:
> > Hello All,
> >
> > This patch was rather long in the making, largely because of
> > incompetence on my part:-(
> > Jerry was very helpful by identifying a bug in the penultimate version
> > and providing an analysis that led directly to a fix. Thanks!
> >
> > As well as fixing PR82649, which I thought previously would require a
> > change in PDT representation, but it fixes bug3-allocate-star-ice.f90
> > and bug15-allocate-len-error-condition.f90 from the attachment to
> > comment #10 in PR82173.
> >
> > (i) bug15-allocate-len-error-condition.f90 is different from the other
> > two but required work in the same part of gfc_trans_allocate:
> >
> > If a LEN parameter is different from an explicit value in the allocate
> > expression,
> > the new function trans-decl.cc(check_PDT_parameters) emits either STAT
> > (and ERRMSG), if code->expr1 (and code->expr2) is available, or a
> > runtime error if -fcheck is set to any value. If neither of these
> > options are available, the processor continues quietly with the
> > allocation. The wrong code works, in the sense that the allocation
> > succeeds and appropriate space is allocated for parameterized arrays
> > and strings. However it violates the standard by changing the value of
> > an explicitly declared LEN value. QUESTION: Should the runtime error
> > be emitted unconditionally if STAT does not appear? I am beginning to
> > think that this should be the case.
> >
> > Constant parameter values could and should be compared in resolve.cc.
> > I will work on this after the last two pending patches in the series
> > are done and dusted.
> >
> > (ii) PR82649 and bug3-allocate-star-ice.f90 both involve allocating
> > dummies with assumed LEN parameters in the type specs for both the
> > dummy declaration and the allocate statement. LEN parameters in these
> > cases should be determined by the values of the actual argument:
> >
> > Previously, the allocation resulted in an ICE. I had thought until
> > very recently that PR82649 could only be fixed by changing the
> > representation of PDTs; such as carrying the values of the LEN
> > parameters in a descriptor. However, a light bulb moment occurred,
> > when I realised that a scalar PDT with the LEN parameters set could be
> > passed as a hidden parameter, in the same way as character lengths.
> > Most of the patch is devoted to this.
> >
> > The first chunk in trans-decl.cc creates the hidden dummy for the
> > function decl. Passing of the hidden dummy is done by the chunk in
> > trans-expr.cc. Note that for both PDTs and class PDTs a scalar PDT is
> > passed. In the case of class PDTs, the type is the declared type of
> > the formal argument. The chunk in trans-types.cc sets the type of the
> > hidden argument. The new function expr.cc
> > (gfc_pdt_requires_hidden_arg) provides the criteria for creating and
> > using the hidden argument. With these changes, the hidden argument is
> > created and passed but does nothing.
> >
> > The new function trans-stamt.cc(check_PDT_parameters) does most of the
> > heavy lifting by updating the parameter list used to allocate the
> > parameterized arrays and strings, by replacing the assumed parameters
> > with explicit ones.
> >
> > To handle class PDT allocations correctly, the allocate type spec
> > type_param_spec_list is copied into a new field in gfc_code,
> > code->ext.alloc.param_list, in match.cc(gfc_match_allocate). Note that
> > this parameter list is deallocated at the end of gfc_trans_allocate
> > since it is not needed and longer.
> >
> > Finally, trans-decl.cc(gfc_trans_deferred_vars) has been updated to
> > ensure that optional dummy PDTs and class PDTs are handled correctly.
> > This is tested in pdt_bug3.f90.
> >
> > (iii) A final wrinkle was noticed when testing the full PDT testsuite
> > in waiting. This fixed in the chunk in resolve.cc. It has nothing to
> > do with the main bugs but increments the ref count of rejected final
> > routine to prevent an ICE during cleanup of the namespace.
> >
> > The patch passes regression testing on FC44/x86_64. OK for mainline?
> >
> > Paul
>
> Ho Paul, I retested all and this looks good. OK for mainline.
>
> Regards,
>
> Jerry
>
> PS Subject missing in email. ;)
>
>
