Le 24/10/2026 à 18:00, Jerry DeLisle a écrit :
On 10/20/26 1:36 PM, Mikael Morin wrote:
Le 20/10/2026 à 22:09, Jerry DeLisle a écrit :
Hi Mikael,
Thanks for the review. You are right on both points. v2 looks up
'_data', '_vptr' and '_len' in the class container of the CLASS
component they follow, and steps through an implicit '_data' to the
declared type for any other name. The walk starts at the associate
name's own container when it is CLASS, so both forms after
gfc_fix_class_refs (explicit '_data' or none) are handled the same way.
v1 only got ref->u.c.sym wrong for those refs (the component pointers
were already right), so nothing failed at run time. The new test
associate_91.f90 uses your foo%class_comp1(4)%class_comp2(:)%bar shape
with a wrong parse-time guess that has the same component names.
That test also exposed a wrong-code bug that trunk has too:
'select type (z => q%a(2)%b(1))' with q an inferred associate name bound
z to the class container instead of its data. The IS_INFERRED_TYPE
branch in trans_associate_var (from PR87477) took the address of the
container as the data pointer. v2 also fixes that, with a check that
skips the branch when se.expr points to a class type.
The change from v1 is the reference loop in
gfc_fixup_inferred_type_refs (resolve.cc) and the one-condition change
in trans_associate_var (trans-stmt.cc); the rest is the two tests.
Regression tested on x86_64.
OK for mainline?
Regards,
Jerry
---
fortran: [PR126968] ICE for wrongly guessed inferred ASSOCIATE type
When an ASSOCIATE selector is a function that has not been parsed yet,
primary.cc types the associate name by guessing: it takes the first
accessible derived type that has a component of the name being
referenced. resolve_assoc_var later corrects the associate name's type
from the resolved selector, and gfc_fixup_inferred_type_refs repaired
the reference chain.
That repair only reset ref->u.c.sym and left ref->u.c.component pointing
into the guessed type. When the guess was wrong, the component and the
type it is referenced from no longer belonged together, which reached
the backend and gave
internal compiler error: in gfc_conv_component_ref, at
fortran/trans-expr.cc:3010
Bind each component reference to the corrected type by looking it up
again by name, walking the whole chain so that nested references are
corrected too. '_data', '_vptr' and '_len' are looked up in the class
container of the CLASS component they follow; any other name after a
CLASS component follows an implicit '_data'. A SELECT TYPE selector
that is an element of such a chain was also bound to the class
container instead of its data, because trans_associate_var took the
address of the container as the data pointer.
Assisted-by: Claude Opus 5.5
PR fortran/126968
gcc/fortran/ChangeLog:
* resolve.cc (gfc_fixup_inferred_type_refs): Look each component
reference up again by name in the corrected derived type and
update both u.c.sym and u.c.component. Walk the whole reference
chain instead of stopping at the first component, looking class
container fields up in the container.
* trans-stmt.cc (trans_associate_var): Do not use the address of
a class container as the data of a scalar CLASS selector.
gcc/testsuite/ChangeLog:
* gfortran.dg/associate_89.f90: New test.
* gfortran.dg/associate_91.f90: New test.
OK, thanks for it.
Thanks Mikael.
Toon also pointed me to an AI generated review from gcc. That's
fascinating.
The attached patch is an updated version to fix a few additional issues.
There are some followup todo's from the AI review I will followup on.
OK for mainline?
Jerry
OK.
