Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
3 Views

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

As per the current Fortran standard (C1254), my reading is NAME= specifier should not be allowed in an ABSTRACT INTERFACE

C1254.png

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?

0 Kudos
10 Replies
Highlighted
3 Views

You are correct. I think we

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

Retired 12/31/2016
0 Kudos
Highlighted
3 Views

This proved to be a more

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

Retired 12/31/2016
0 Kudos
Highlighted
Black Belt
3 Views

I have a related, but

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

 

0 Kudos
Highlighted
3 Views

There is no purpose - that's

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

Retired 12/31/2016
0 Kudos
Highlighted
Valued Contributor III
3 Views

And that's why I brought this

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.

0 Kudos
Highlighted
3 Views

Fixed for a release later

Fixed for a release later this year.

Retired 12/31/2016
0 Kudos
Highlighted
Valued Contributor III
3 Views

Very good, thanks.

Very good, thanks.

0 Kudos
Highlighted
Valued Contributor III
3 Views

Steve,

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)

 

0 Kudos
Highlighted
3 Views

Argh... Ok, thanks.

Argh... Ok, thanks.

Retired 12/31/2016
0 Kudos
Highlighted
3 Views

Ok, this time for sure!

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

Retired 12/31/2016
0 Kudos