- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You are correct. I think we recently fixed some issues in this area - I will check on Monday.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,..
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is no purpose - that's why it's not allowed by the language.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Fixed for a release later this year.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Very good, thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Argh... Ok, thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, this time for sure! Should be fixed properly in 16.0.3.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page