Compiler 15, update 1 allows NAME= specifier in an ABSTRACT INTERFACE; is it right?

[FortranFan]

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

Comments?

[Steven_L_Intel1]

You are correct. I think we recently fixed some issues in this area - I will check on Monday.

[Steven_L_Intel1]

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).

[mecej4]

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,..

[Steven_L_Intel1]

There is no purpose - that's why it's not allowed by the language.

[FortranFan]

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.

[Steven_L_Intel1]

Fixed for a release later this year.

[FortranFan]

Very good, thanks.

[FortranFan]

Steve,

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 16.0.1.146 [Intel(R) 64]...
m.f90

m - 0 error(s), 0 warning(s)

[Steven_L_Intel1]

Argh... Ok, thanks.

[Steven_L_Intel1]

Ok, this time for sure! Should be fixed properly in 16.0.3.