Hello Jerry, The patch does what it is supposed to do and LGTM :-)
OK for mainline. Cheers Paul On Tue, 27 Oct 2026 at 14:55, Jerry DeLisle <[email protected]> wrote: > > See the attached patch. > > This one discovered while working on PR126968. In the meantime, a > regressionwas > found on the PR126968 commit with -m32. I forgot to get the LD_LIBRARY_PATH > set > right so did not see the failure. I will have another followup patch for the > regression which is a result of the search order looking for the correct > names. > More explanation will follow when I submit that one. > > Regression tested on x86_64. > > OK for mainline? > > Best regards, > > Jerry > > --- > > fortran: [PR128144] ICE for type-bound call through inferred ASSOCIATE name > > When an ASSOCIATE selector is a contained function that has not been > parsed yet, the associate name gets a guessed type and its references > are fixed up during resolution by gfc_fixup_inferred_type_refs. That > only happened for variables. A type-bound procedure call or a procedure > pointer component call through the associate name, such as > q%c2%get (), kept the references built from the guess: the '_data' > reference after a CLASS associate name was missing, components could > belong to the wrongly guessed type, and the binding itself had been > looked up in that type. This gave > > internal compiler error: in gfc_conv_component_ref, at > fortran/trans-expr.cc:2939 > > or, with a wrong guess, a call of the wrong procedure or a bogus type > mismatch error. > > Fix up the references of these calls in the same way before they are > resolved, and look the binding up again in the corrected type. The > call of gfc_fixup_inferred_type_refs in gfc_conv_variable, which was > meant to catch expressions that escaped resolution, now finds nothing > to do, and it misbehaved on reference chains that callers cut short > temporarily, so remove it. > > For an element of an array valued associate name of this kind, the > array reference has no array spec, so find_array_spec is used. It did > not take the array spec of a CLASS array component, which is held by > its '_data' component, and rejected valid code such as > size (q(1)%c2) with "Invalid array reference of a non-array entity". > Use the array spec of the '_data' component when the array reference > follows the CLASS component directly. > > PR fortran/128144 > > gcc/fortran/ChangeLog: > > * resolve.cc (find_array_spec): Handle CLASS array components > followed directly by an array reference. > (fixup_inferred_compcall_refs): New function. > (resolve_typebound_function, resolve_typebound_subroutine) > (resolve_ppc_call, resolve_expr_ppc): Use it. > * trans-expr.cc (gfc_conv_variable): Do not call > gfc_fixup_inferred_type_refs. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/associate_95.f90: New test. > * gfortran.dg/associate_96.f90: New test. > ---
