On 12/5/25 3:24 AM, Paul Richard Thomas wrote:
Hi All,
All these patches represent steps towards persuading fiats to build and
test successfully. Jerry and I have had all of them on our trees for
some weeks now and I think that the time has come for them to be pushed
before bit rot sets in. Fiats makes heavy use of PDTs, ASSOCIATE and
other modern features that have been a challenge for all the compiler
brands, as well as gfortran.
It looks as if there is one big remaining blocker that Damian is working
on finding a short reproducer for. In the meantime, I want to get shot
of this lot and to tackle some of the more challenging, remaining PDT
bugs. While I have submitted the patches in a batch, I promise that I
will push them separately :-) Happily, each PR appears as a separate
package in alphabetic order of the touched fortran directory members.
The fix for PR122693 comprises the chunksarray.cc
(gfc_match_array_constructor). In some circumstances processing PDT
typespecs leads to a return in a different namespace. The fix is trivial
and described in the ChangeLog.
That for PR122670 appears in the chunks in decl.cc
(gfc_get_pdt_instance) and module.cc (read_module). The latter fixed the
original problem by using PDT instances, when the template appears in a
USE ONLY statement. The former fixes the corresponding problem for
IMPORT statements. Both fixes are straight forward.
PR122578 is fixed by the chunks in primary.cc (gfc_match_varspec):
Typebound generic procedure or procedure component selector expressions
appear frequently in fiats nested ASSOCIATE statements and so it is
important to obtain the specific procedure to feed as the selector for
the nested ASSOCIATE. In both chunks, attempting resolution of the
selector must be done with a copy of the selector expression to prevent
the sometimes mutilated expressions that are returned on failure.
Selecting candidate expressions for resolution is straightforward.
Finally, PR122669 is fixed in resolve.cc (resolve_allocate_deallocate)
and involved array allocation with MOLD expressions without an array
spec, using an expression with constant bounds. This was fixed by
resolving the MOLD expression for each allocate object, rather than as a
loop invariant.
The fixes all regtest on FC43/x86_64. OK for mainline?
Best regards
Paul
I looked through the set, looks good. Applied to latest trunk. Builds good.
Regression tested one more time.
OK for mainline and we move forward!
Thanks,
Jerry
-------------------------------------------
Native configuration is x86_64-pc-linux-gnu
=== gfortran tests ===
Running target unix
=== gfortran Summary ===
# of expected passes 74558
# of expected failures 343
# of unsupported tests 82
/home/jerry/dev/objdir/gcc/gfortran version 16.0.0 20251205
(experimental) (GCC)
