On Thu, Oct 23, 2025 at 07:17:37PM +0000, Harald Anlauf wrote: > Hi Paul! > > > Gesendet: Donnerstag, 23. Oktober 2025 um 15:14 > > Von: "Paul Richard Thomas" <[email protected]> > > An: "Harald Anlauf" <[email protected]> > > CC: "[email protected]" <[email protected]>, "Jerry DeLisle" > > <[email protected]>, "Damian Rouson" <[email protected]> > > Betreff: Re: [Patch, fortran] PR122290 - PDT - gfortan rejects real > > intrinsic in default initialization & generic binding > > > It turns out that the assignment statements on lines 54 and 60 are the > > cause of the problem. pdt_39.f03 uses the pdt_kind initializer branch > > in simplify.cc(get_kind). In that case, simplification is not possible > > and so the corrected 'kind' expression must be fed to > > gfc_resolve_real. It is not so for pdt_60.f03 and so the residual > > 'memory' of 'kind' is carried through to clean-up and causes the > > valgrind errors. I am trying to find a solution that doesn't involve > > modification of every single user of get_kind or does not provide an > > equivalent in iresolve.cc. Thus far, I have only found rabbit holes. > > > > If the solution turns out to be as messy as I suspect it will be, I > > propose that this patch be pushed as it is and that an initial PR be > > raised to cover the necessary subsequent patch. > > Allright, so let's make an exception and go ahead if nobody else objects. >
I do not object. From Paul's description, I think I've gone down some of the rabbit holes that he is finding. Paul, do think introducing a BT_TYPE_PARAM enum and delaying handling until resolution phase may help prevent the rabbit holes? -- Steve
