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