[Bug fortran/125531] Inferred-type ASSOCIATE name gives spurious "Expected argument list" when data component shares name

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125531

--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
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)