The attach patch has been regression tested on x86_64-*-freebsd.
If the pointer is NULL, the function simply returns. It seems
that gfortran then does the Right Thing. OK to commit?
2019-06-18 Steven G. Kargl <[email protected]>
PR fortran/87907
* resolve.c (resolve_contained_fntype): Do not dereference a NULL
pointer.
2019-06-18 Steven G. Kargl <[email protected]>
PR fortran/87907
* gfortran.dg/pr87907.f90: New testcase.
--
Steve
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 272432)
+++ gcc/fortran/resolve.c (working copy)
@@ -583,6 +583,9 @@ resolve_contained_fntype (gfc_symbol *sym, gfc_namespa
|| sym->attr.entry_master)
return;
+ if (!sym->result)
+ return;
+
/* Try to find out of what the return type is. */
if (sym->result->ts.type == BT_UNKNOWN && sym->result->ts.interface == NULL)
{
Index: gcc/testsuite/gfortran.dg/pr87907.f90
===================================================================
--- gcc/testsuite/gfortran.dg/pr87907.f90 (nonexistent)
+++ gcc/testsuite/gfortran.dg/pr87907.f90 (working copy)
@@ -0,0 +1,23 @@
+! { dg-do compile }
+! PR fortran/pr87907
+! Original testcase contributed by Gerhard Stienmetz <gscfq at t-online dot de>
+module m
+ interface
+ module function g(x) result(z)
+ integer, intent(in) :: x
+ integer, allocatable :: z
+ end
+ end interface
+end
+
+submodule(m) m2
+ contains
+ subroutine g(x) ! { dg-error "mismatch in argument" }
+ end
+end
+
+program p
+ use m ! { dg-error "has a type" }
+ integer :: x = 3
+ call g(x) ! { dg-error "which is not consistent with" }
+end
