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. > ---
