https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88632
--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> --- (In reply to Paul Thomas from comment #2) > Created attachment 45349 [details] > A provisional patch that fixes the problem > > The attached fixes this but causes regressions: > > FAIL: gfortran.dg/module_private_2.f90 -O scan-tree-dump-times optimized > "priv" 0 > FAIL: gfortran.dg/public_private_module_7.f90 -O scan-assembler-not > __m_common_attrs_MOD_other > FAIL: gfortran.dg/public_private_module_8.f90 -O scan-assembler-not > __m_MOD_myotherlen > FAIL: gfortran.dg/public_private_module_2.f90 -O scan-assembler-not two > FAIL: gfortran.dg/public_private_module_2.f90 -O scan-assembler-not six > FAIL: gfortran.dg/warn_unused_function_2.f90 -O (test for warnings, line > 16) > > I think that this is best dealt with by extending the patch by flagging the > module as having a module function/subroutine, which implies that there is a > submodule somewhere, and making all the module procedures TREE_PUBLIC. That > will suppress the above regressions. > > Otherwise, I will have to find someway of persuading the linker to find the > symbol from the submodule. > > First I must get the C-interop patch out of the way and then I will come > back to this PR. > > Paul The C-interop patch is all but gone: just one bug to go. This PR is therefore now on my radar. Paul
