When an ASSOCIATE construct uses a contained function as its selector and the result type has a data component whose name also matches a type-bound procedure name, gfortran spuriously rejects the data-component access with "Expected argument list". program test implicit none type :: args_t integer :: order_ = 4 integer :: cells_ = 20 double precision :: x_min_ = 0d0, x_max_ = 1d0 end type associate (args => get_args ()) associate (result => compute (args%order_, args%cells_)) print *, result end associate end associate contains function get_args () result (r) type(args_t) :: r r%order_ = 2 r%cells_ = 10 end function function compute (order, cells) result (r) integer, intent(in) :: order, cells integer :: r r = order * cells end function end program $ gfortran associate_infer_program_type.f90 gfortran rejects args%order_ and args%cells_ with "Expected argument list". The program should compile and run cleanly.
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>: https://gcc.gnu.org/g:418c6b5fbab2b3bf5e7727657172864ae5440c1d commit r17-1394-g418c6b5fbab2b3bf5e7727657172864ae5440c1d Author: Jerry DeLisle <jvdelisle@gcc.gnu.org> 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.
The releases/gcc-16 branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>: https://gcc.gnu.org/g:1386faee4600160c9a0f85f683d6c1c65d282099 commit r16-9104-g1386faee4600160c9a0f85f683d6c1c65d282099 Author: Jerry DeLisle <jvdelisle@gcc.gnu.org> 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. (cherry picked from commit 1572da928e4f067cb45c511156899bda1d73e593)
Fixed and closing