On 10/28/26 10:55 AM, Paul Richard Thomas wrote:
Hello Jerry,
The patch does what it is supposed to do and LGTM :-)
OK for mainline.
Cheers
Paul
Thanks Paul,
The master branch has been updated by Jerry DeLisle <[email protected]>:
https://gcc.gnu.org/g:db896263a5f476223958cf9ffeb1922759601362
commit r17-5670-gdb896263a5f476223958cf9ffeb1922759601362
Author: Jerry DeLisle <[email protected]>
Regards,
Jerry
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.
---
