Thanks Paul. The master branch has been updated by Jerry DeLisle <[email protected]>:
https://gcc.gnu.org/g:d3d984e9a0670b8b1076089e2cbc85f9a58578b6 commit r17-1148-gd3d984e9a0670b8b1076089e2cbc85f9a58578b6 Author: Jerry DeLisle <[email protected]> Date: Mon May 25 09:29:33 2026 -0700 fortran: submodule cannot access internal subprograms of ancestor module via host association On 6/1/26 2:15 PM, Paul Richard Thomas wrote:
Hi Jerry, The mea-bug is 121381, is it not? The patch looks good to me and regtests just fine on FC44/x86_64. OK for mainline and, after a decent interval, for backporting. Cheers Paul On Mon, 1 Jun 2026 at 21:30, Jerry D <[email protected]> wrote:See attached patch. This fixes the problem as noted in the change log. This is one of the several listed in the meta bug PR125515. I will be submitting these one at a time for review so we don;t get lost in it. Regression tested on x86_64. OK for mainline and then backport to 16 after a wait. Regards, Jerry --- 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. ---
