Thanks, Jerry! Pushed as r17-5389.
Cheers Paul On Mon, 19 Oct 2026 at 18:11, Jerry D <[email protected]> wrote: > > On 10/19/26 4:25 AM, Paul Richard Thomas wrote: > > Hello All, > > > > Jerry used Claude to review all of the submissions in this series that > > have been posted to date. This was the report on this one: > > Patch: 6 (bug9/10) > > Verdict: Blocker: typed ALLOCATE into class(*) takes its LEN > > from the shared per-KIND instance, so base(4,5) after > > base(4,3) gets n=3, and a runtime LEN gets the default of 1. > > That is silent wrong code where master segfaulted. Blocker: > > the temporary leaks 12 bytes per ALLOCATE > > > > The memory leak is still not fixed, being a generic PDT problem that I > > will return to once this series is completed. > > > > The rest of the report was straightforward to address and I was about > > to resubmit a week ago. However, just to veer on the side of caution, > > I tried variants of the testcase and found, to my horror, that > > reducing the number of allocate/call selectors in the main program to > > 2 resulted in: > > bug9-class-is-kind-ice.f90:30:21: > > > > 30 | class is (base(16, *)) ! ditto > > | 1 > > Error: Keyword argument âkâ at (1) is not in the procedure > > > > Reducing them to 1 such pair resulted in an ICE. > > > > For either of these failing cases, either putting the subroutine > > select in the module or adding a 'type is (integer(4)) before the > > CLASS IS statements or including in selector declarations of > > allocatable variable of each of the CLASS IS types, then allocating > > them, fixed these problems. The latter kludge led me and then Claude > > down many rabbit holes before the line "type_param_spec_list = NULL;" > > in match.cc was added. I had tried this early on but it didn't work. > > Clearly some other part or parts of the patch was necessary as well. I > > started investigating, without joy, but I am frankly so sick and tired > > of this bug that I gave up on it. > > > > The attached patch passes regression testing. OK for mainline, on > > condition that I come back to the memory leaks on a later date? > > > > Regards > > > > Paul > > > > On Thu, 8 Oct 2026 at 13:35, Paul Richard Thomas > > <[email protected]> wrote: > >> > >> bug9-class-is-kind-ice.f90:35:16: > >> > >> 35 | class is (base(8, *)) ! distinct guards - C1168 permits > >> this > >> | 1 > >> Error: Double CLASS IS block in SELECT TYPE statement at (1) > >> > >> bug10-unlimited-poly-alloc-len.f90 failed in runtime: > >> Program received signal SIGSEGV: Segmentation fault - invalid memory > >> reference. > >> ....etc.,etc..... > >> > >> The fixes are inter-dependent and so come in a single patch. > >> > >> The chunks in gfortran.h and resolve.cc are sufficiently explained in > >> the ChangeLog entries. > >> > >> The first three chunks in trans-stmt.cc convert the PDT structure > >> constructor, emanating from the ALLOCATE typespec, convert it to a > >> type parameter list and append it to the initialization expression. > >> > >> Chunk 4, then exploits the so appended initialization expression or if > >> it is not available and the MOLD expr3 is a PDT structure constructor, > >> does a likewise conversion of expr3. The parameterized components are > >> then allocated and the result used as the rhs in the assignment to the > >> allocated expression. > >> > >> Passes regtesting on FC44/x86_64. OK for mainline. > >> > >> Cheers > >> > >> Paul > > Yes OK, applies and tests clean here. > > Thanks for the work? > > Jerry
