Committed as r16-3308. Thanks, Jerry.
Paul On Wed, 20 Aug 2025 at 19:27, Jerry D <jvdelis...@gmail.com> wrote: > On 8/20/25 8:54 AM, Paul Richard Thomas wrote: > > Hi Jerry, > > > > The attached patch fixes both pr84122 and pr85942. Beyond the more > > elaborate chunk in parse.cc, a new chunk was required in > > simplify.cc(get_kind) to convert KIND expressions involving PDT kind > > parameters into viable initialization expressions. Both are straight > > forward. > > > > The patch regtests on FC42/x86_64. OK for mainline? > > > > The next PDT patch, to be posted tomorrow, corrects the invalid PDT > > constructors present in pft_22/23.f03. The change is from my_pdt (all > > components) to my_pdt (type parms)(the rest of the components). > > Following this will be a patch to fix list directed IO of a PDT object > > so that the type parameters do not appear. A few more parse errors will > > be fixed before I hit the representation of PDTs(pr82649). > > > > Cheers > > > > Paul > > > > All good Paul, proceed. > > Thanks, > > Jerry > > > On Tue, 19 Aug 2025 at 17:23, Paul Richard Thomas > > <paul.richard.tho...@gmail.com <mailto:paul.richard.tho...@gmail.com>> > > wrote: > > > > Hi Jerry, > > > > Thanks for taking a look at it but I have to withdraw this patch for > > a short while. It suppresses legal declarations like(pr85942): > > type, public :: mat_t(k,c,r) > > !.. type parameters > > integer, kind :: k = r4 > > integer, len :: c = 1 > > integer, len :: r = 1 > > private > > !.. private by default > > !.. type data > > real(kind=k) :: m_a(c,r) > > end type mat_t > > > > Sorry about that. > > > > Thanks again > > > > Paul > > > >
