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 On 6/5/26 11:20 PM, Paul Richard Thomas wrote:
Hi Jerry, It looks OK to me, except for one minor omission: +! "Invalid association target" because:......? OK for mainline and for backporting. NOTE TO SELF: I must revive the attempt at two pass parsing. Thanks for the patch. Paul On Fri, 5 Jun 2026 at 20:28, Jerry D <[email protected]> wrote:See attached patch. This one is also fairly straight forward. Regression tested on x86_64. OK for mainline and then backport to 16? Regards, Jerry --- 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. ---
