https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88632
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 45349
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45349&action=edit
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
