https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124189
--- Comment #1 from Steve Kargl <kargl at gcc dot gnu.org> ---
This patch allows the code in the original bug report to compile
and execute.
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 655db8a1c9c..2cb8b0b3901 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -3968,6 +3968,12 @@ check_sym_import_status (gfc_symbol *sym, gfc_symtree
*s, gfc_expr *e,
if (e && e->expr_type == EXPR_FUNCTION && sym->attr.vtype)
return true;
+ /* If an intrinsic subprogram appears in the host scoping unit, it is
+ included in its namespace. Neither 'import, none' nor 'import, only'
+ should block it due to host association. */
+ if (e && e->expr_type == EXPR_FUNCTION && e->value.function.isym)
+ return true;
+
if (e)
here = &e->where;
else
However, things go a bit sideways with external functions.
program foo
real x
x = 1.245
x = bar(x) ! This use of bar()
print *, x
call sub
contains
subroutine sub
import, none ! and this statement
real x
x = 3.
x = bar(x) ! causes an error here.
print *, x
end subroutine sub
end
function bar(y)
real bar
real, intent(in) :: y
bar = y * 42
end function
bar() in subroutine sub is a reference to an external
function. It is unclear to me if the implied type
in the main program should be considered for host
association or not. If the first use of bar() in
the main program is comment out, the code compiles
with implicit typing for bar() in sub.
