As per the current Fortran standard (C1254), my reading is NAME= specifier should not be allowed in an ABSTRACT INTERFACE
but the compiler raises no errors or warnings with the following code:
MODULE m USE, INTRINSIC :: ISO_C_BINDING, ONLY : C_INT !.. IMPLICIT NONE !.. ABSTRACT INTERFACE FUNCTION foo() RESULT(RetVal) BIND(C, NAME="foo") IMPORT :: C_INT !.. Function result INTEGER(C_INT) :: RetVal END FUNCTION foo SUBROUTINE bar() BIND(C, NAME="bar") END SUBROUTINE bar END INTERFACE END MODULE m
This proved to be a more interesting issue than I first thought.
First of all, you are indeed correct - NAME= is not allowed to be specified for a proc-language-binding-spec in an abstract interface, in both F2003 and F2008. The compiler similarly fails to give an error for this usage in the interface for a dummy argument. Both of these have been reported as issue DPD200365350.
I also noticed that the standard changed subtly in this area between F2003 and F2008. In F2003, you were not allowed BIND(C) for an internal procedure at all. F2008 permits it as long as you don't also say NAME=. We currently enforce the F2003 language and disallow this - I have added this to our list of things to do for F2008 (DPD200365351).
I have a related, but different question. What is the purpose of specifying a name with a NAME= clause, given that an abstract interface is a prototype (or template, if you will) of a not-yet-declared procedure? The name is to be expected in a subsequent declaration such as
procedure (abstract_proc_prototype) :: proc_abc
and "proc_abc" is the name of the procedure. We could even have more than one such name, as in
procedure (abstract_proc_prototype) :: proc_abc, proc_pqr,..
And that's why I brought this up: I was reviewing some code in our group and noticed a specific interface to an external procedure that got introduced inadvertently into an abstract interface block. Obviously it didn't make sense. So we figured the best way to prevent this in the future will be if the compiler flagged it as an issue.
Per Intel compiler 16 fixes list (https://software.intel.com/en-us/articles/intel-parallel-studio-xe-2016-composer-edition-compilers-fixes-list), it appears DPD200365350 was considered resolved. However it only seems to have fixed the subroutine aspect; the issue remains with function statements:
module m use, intrinsic :: iso_c_binding, only : c_int implicit none abstract interface function foo() result(RetVal) bind(C, name="foo") import :: c_int !.. Function result integer(c_int) :: RetVal end function foo end interface end module m
Compiling with Intel(R) Visual Fortran Compiler 184.108.40.206 [Intel(R) 64]... m.f90 m - 0 error(s), 0 warning(s)