The attached patch has been tested on x86_64-*-freebsd. PR fortran/77960 uses a procedure pointer to expose the bug, but it applied to any external subprogram. So, the patch checks for the external attribute. OK to commit?
2019-01-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/77960 * io.c (match_io_element): input-item cannot be an external function. 2019-01-19 Steven G. Kargl <ka...@gcc.gnu.org> PR fortran/77960 * gfortran.dg/pr77960.f90: New test. -- Steve
Index: gcc/fortran/io.c =================================================================== --- gcc/fortran/io.c (revision 268095) +++ gcc/fortran/io.c (working copy) @@ -3610,6 +3610,16 @@ match_io_element (io_kind k, gfc_code **cpp) m = gfc_match_variable (&expr, 0); if (m == MATCH_NO) gfc_error ("Expected variable in READ statement at %C"); + + if (m == MATCH_YES + && expr->expr_type == EXPR_VARIABLE + && expr->symtree->n.sym->attr.external) + { + gfc_error ("Expecting variable or io-implied-do at %L", + &expr->where); + m = MATCH_ERROR; + } + } else { Index: gcc/testsuite/gfortran.dg/pr77960.f90 =================================================================== --- gcc/testsuite/gfortran.dg/pr77960.f90 (nonexistent) +++ gcc/testsuite/gfortran.dg/pr77960.f90 (working copy) @@ -0,0 +1,16 @@ +! { dg-do compile } +! PR fortran/77960 + procedure(g), pointer :: f + f => g + read(99) f ! { dg-error "Expecting variable" } +contains + function g() result(z) + integer :: z(2) + z = 1 + end +end + +subroutine bar(x) + integer, external :: x + read(*,*) x ! { dg-error "Expecting variable" } +end subroutine