[Bug fortran/125527] Submodule cannot access internal subprograms of ancestor module via host association

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jerry DeLisle <jvdelisle@gcc.gnu.org>:

https://gcc.gnu.org/g:d3d984e9a0670b8b1076089e2cbc85f9a58578b6

commit r17-1148-gd3d984e9a0670b8b1076089e2cbc85f9a58578b6
Author: Jerry DeLisle <jvdelisle@gcc.gnu.org>
Date:   Mon May 25 09:29:33 2026 -0700

    fortran: submodule cannot access internal subprograms of ancestor module
via host association

    A submodule could not access internal subprograms of its ancestor module
    via host association.  References to such procedures were rejected with
    "has no IMPLICIT type".  Fortran 2018 §14.6.1.3 requires submodules to
    host-associate the specification part and the module subprogram part of
    their ancestor module; Intel Fortran and NAG Fortran accept this usage.

    Root cause: when parse_module processes a submodule, gfc_current_ns->parent
    is left NULL, so the host-association walk cannot reach the ancestor
    module's namespace and its internal procedures.

    Fix (parse.cc, parse_module): after use_modules() and gfc_traverse_ns(),
    strip the child suffix from the submodule's dotted name (e.g. "m.s" ->
"m"),
    search gfc_global_ns_list for the matching ancestor namespace, and set
    gfc_current_ns->parent to it.

    Fix (parse.cc, clean_up_modules): before calling gfc_done_2(), reset
    gfc_current_ns->parent to NULL to prevent gfc_symbol_done_2 from walking up
    to and double-freeing the ancestor module namespace during teardown.

    The new parent link also required boundary guards in three places that walk
    up the namespace chain:

    Fix (class.cc, gfc_find_derived_vtab): the vtab lookup walks up ns->parent
    to find the top-level namespace.  Stop at module/submodule boundaries
    (FL_MODULE flavor) so that vtables for types defined in a submodule are not
    incorrectly placed in the ancestor module namespace.

    Fix (openmp.cc, gfc_omp_requires_add_clause, gfc_match_omp_requires,
    gfc_match_omp_atomic): three OpenMP helpers walk ns->parent to find the
    enclosing program unit.  Each acquired the same boundary guard so the
    submodule is treated as its own program unit for OMP REQUIRES purposes.

    PR fortran/125527

    Assisted by: Claude Sonnet 4.6

    gcc/fortran/ChangeLog:

            PR fortran/125527
            * class.cc (gfc_find_derived_vtab): Stop the top-level namespace
            walk at module/submodule boundaries to avoid escaping a submodule
            into its ancestor module namespace.
            * openmp.cc (gfc_omp_requires_add_clause): Likewise; treat the
            submodule as its own program unit for OMP REQUIRES.
            (gfc_match_omp_requires): Likewise; allow OMP REQUIRES in a
submodule
            spec part even when gfc_current_ns->parent is now non-NULL.
            (gfc_match_omp_atomic): Likewise.
            * parse.cc (parse_module): After processing USE statements and
            host-association traversal, link the submodule namespace to its
            ancestor module namespace so internal subprograms are visible via
            host association (Fortran 2018, 14.6.1.3).
            (clean_up_modules): Reset gfc_current_ns->parent before gfc_done_2
            to prevent double-free of the ancestor module namespace.

    gcc/testsuite/ChangeLog:

            PR fortran/125527
            * gfortran.dg/submodule_host_assoc_1.f90: New test.
            * gfortran.dg/submodule_host_assoc_1_aux.f90: New test.