https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125531
--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jerry DeLisle <[email protected]>: https://gcc.gnu.org/g:418c6b5fbab2b3bf5e7727657172864ae5440c1d commit r17-1394-g418c6b5fbab2b3bf5e7727657172864ae5440c1d Author: Jerry DeLisle <[email protected]> Date: Sat Jun 6 09:47:59 2026 -0700 fortran: inferred-type ASSOCIATE name giving spurious "Expected argument list" In gfc_match_varspec, when parsing component references on an inferred-type ASSOCIATE name, the parser incorrectly matched the component name as a type-bound procedure . For inferred-type ASSOCIATE names the parse-time candidate type may differ from the final resolved type. If gfc_find_component fails with the default access check, retry with noaccess=true; the resolution pass will substitute the correct type. Assisted by: Claude Sonnet 4.6 PR fortran/125531 gcc/fortran/ChangeLog: * primary.cc (gfc_match_varspec): Before erroring on a zero-argument COMPCALL, check for a same-named data component and fall back to the data-component path. For inferred-type ASSOCIATE names, retry gfc_find_component with noaccess=true when the normal search fails. gcc/testsuite/ChangeLog: * gfortran.dg/associate_infer_program_type.f90: New test.
