Hi Harald, Thanks for that :-(
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. @jerry, @damian Please use the patch as it stands to press on with testing. I am eager to eke out as many PDT bugs as possible from real life production code. Best regards Paul PS When I said that I would take a look at PR71565 on my return, I meant that I would look at your final patch and not that I was elbowing you out! Sorry for the confusion. On Wed, 22 Oct 2025 at 20:40, Harald Anlauf <[email protected]> wrote: > > Am 22.10.25 um 17:40 schrieb Paul Richard Thomas: > > This patch turned out to be straightforward once the source of the > > problems were identified: > > > > The problem with type matching came about because the component > > initializers were given BT_UNKNOWN before reduction was done. This was > > cured by giving the untreated initializers the same type as the > > component. > > > > Matching the template component initializers must be done with > > gfc_match_expr to prevent the reduction in gfc_match_init_expr from > > rendering them unusable for the PDT instances or to avoid the errors > > resulting from parameterized expressions. > > > > Where necessary, initializer expressions must have the parameter > > values substituted. > > > > Finally, generic intrinsic ops attempt to add the same entities to > > interfaces for each PDT instance. Suppress this in the same way as for > > entities used in submodules. > > > > The new testcase is an expanded version of the reporter's to check > > that the correct procedures are selected, when the intrinsic operators > > are referenced. > > > > Regtests on FC42/x86_64. OK for mainline? > > > > Paul > > Hi Paul, > > this looks good at first sight. > > I ran the new f951 under valgrind on the new testcase and hit > an invalid read: > > ==8558== Invalid read of size 8 > ==8558== at 0xB1EB36: get_kind(bt, gfc_expr*, char const*, int) > (simplify.cc:133) > ==8558== by 0xB31558: gfc_simplify_real(gfc_expr*, gfc_expr*) > (simplify.cc:7547) > ==8558== by 0xA6E149: do_simplify(gfc_intrinsic_sym*, gfc_expr*) > (intrinsic.cc:4895) > ==8558== by 0xA7A49A: gfc_intrinsic_func_interface(gfc_expr*, int) > (intrinsic.cc:5298) > ==8558== by 0xAEED5B: resolve_unknown_f(gfc_expr*) (resolve.cc:3106) > ==8558== by 0xAEFCBE: resolve_function(gfc_expr*) (resolve.cc:3533) > ==8558== by 0xAFAFE8: gfc_resolve_expr(gfc_expr*) (resolve.cc:8181) > ==8558== by 0xB099C0: gfc_resolve_code(gfc_code*, gfc_namespace*) > (resolve.cc:13878) > ==8558== by 0xB18EDB: resolve_codes(gfc_namespace*) (resolve.cc:19897) > ==8558== by 0xB18FAC: gfc_resolve(gfc_namespace*) (resolve.cc:19932) > ==8558== by 0xADC576: resolve_all_program_units(gfc_namespace*) > (parse.cc:7481) > ==8558== by 0xADCD85: gfc_parse_file() (parse.cc:7741) > > Maybe this can be traced back to a code path where a variable > is not suitably initialized` > > Best, > Harald >
