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.
