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 > > Hi Harald, > > Thanks for that :-(
Sorry 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. Allright, so let's make an exception and go ahead if nobody else objects. Note that since my compiler ICEs here on pdt_60.f03 under MALLOC_PERTURB_=3 I would not be surprised if some other platform will show a testsuite failure. You might still want to fix these spelling issues in the commit message: s/initailizers/initializers/ s/enities/entities/ Thanks for the patch! Harald > @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 > > >
