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