Thanks, Jerry! Pushed to mainline as: 122578 r16-5933 122669 r16-5934 122670 r16-5935 122693 r16-5936
and BTY: 103371 r16-5848 (I don't think that I confirmed that this had been pushed.) Regards Paul On Fri, 5 Dec 2025 at 18:21, Jerry D <[email protected]> wrote: > 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) > >
