Is this standard Fortran 2008?

[OP1]

Is this code standard Fortran 2008?

MODULE PRECISION
IMPLICIT NONE
INTEGER,PARAMETER :: DP = 8
END MODULE PRECISION
MODULE M
USE PRECISION
IMPLICIT NONE
INTERFACE
    REAL(KIND=DP) MODULE FUNCTION F(X)
        REAL(KIND=DP),INTENT(IN) :: X
    END FUNCTION F
END INTERFACE
END MODULE M

I have another compiler who complains that DP in the "REAL(KIND=DP) MODULE FUNCTION F(X)" statement is not defined.
 

[Steven_L_Intel1]

No - the other compiler is correct. It looks as if we're not properly handling this case. I will let the developers know. Issue ID DPD200372530.

[OP1]

Thanks Steve!

What are the consequences of this bug? In other words, is the function interpreted as a REAL(KIND=4) as opposed to REAL(KIND=8)? I am wondering if this is related to the other issues I have encountered today.

[FortranFan]

Steve Lionel (Intel) wrote:

No - the other compiler is correct. It looks as if we're not properly handling this case. I will let the developers know. Issue ID DPD200372530.

Steve,

I think the code as shown in the original post is compliant with Fortran 2008 standard.  Consider the enhanced facilities provided by the addition of submodules to the Fortran 2008 standard: one can now have separate module procedures and both the interface and submodules now have access to entities by host association.  So the code should work ok.

By the way, see this thread for a simple example in action: https://software.intel.com/en-us/forums/topic/549513.  How the interface in this example has gained access to type t should be the same as for DP in this thread and note how the syntax for "module function" is similar.

[Steven_L_Intel1]

Sorry, I answered the wrong question. The code IS standard, Intel Fortran is incorrect in not saying so. In an interface block, no host association occurs. You'd need IMPORT or USE to get that to compile if the compiler properly enforced the standard.

[FortranFan]

Steve Lionel (Intel) wrote:

... The code IS standard, Intel Fortran is incorrect in not saying so. In an interface block, no host association occurs. You'd need IMPORT or USE to get that to compile if the compiler properly enforced the standard.

OP says some other compiler complains, but doesn't mention Intel Fortran's response for the code.

For me, Intel Fortran 16.0 beta, update 2 works fine with the above code since it has the submodule and related functionality from Fortran 2008 implemented.

[OP1]

Some clarification: with the original code, (1) the Cray compiler complains, and I think it does so rightly; (2) the Intel compiler doesn't (16 Beta 2) and it should complain.

After thinking about it, I think there is a subtle distinction between MODULE procedures and simple interface blocks. See this new program:

MODULE PRECISION
IMPLICIT NONE
INTEGER,PARAMETER :: DP = 8
END MODULE PRECISION
MODULE M
USE PRECISION
IMPLICIT NONE
INTERFACE
    MODULE FUNCTION F(X)
        REAL(KIND=DP) :: F
        REAL(KIND=DP),INTENT(IN) :: X
    END FUNCTION F
    SUBROUTINE S(X)
        IMPORT :: DP
        REAL(KIND=DP),INTENT(IN) :: X
    END SUBROUTINE S
END INTERFACE
CONTAINS
    REAL(KIND=DP) FUNCTION G(X)
        IMPLICIT NONE
        REAL(KIND=DP),INTENT(IN) :: X
        G = X
    END FUNCTION G
END MODULE M

This code compiles with both compilers.

[FortranFan]

Yes, there is a difference between module procedures and simple interface blocks.  See Fortran TR 19767 that formed the basis for submodules in the Fortran 2008 standard.  It shows:

What you showed in the original post has a module procedure: so I think Intel Fortran per the submodule implementation in 16.0, update 2 is correct.

What is the error you get for the code in the original post with Cray compiler?

[OP1]

I think the issue is with the "DP" in the REAL(KIND=DP) MODULE FUNCTION... line (what the Cray compiler indicates). Technically speaking (or, at least, syntactically), it lies 'outside' the module function interface body. Since, as pointed by Steve, an interface block does not inherit the content of its parent module by host association, it is therefore undefined. 

This is why an IMPORT statement is required for regular procedure interfaces; whereas the module procedures are exempt from this, most likely because the actual procedure will be CONTAINed in a submodule, and therefore will have access to DP (for the definitions INSIDE the interface body) in this particular example.

But I may be completely wrong in my interpretation. In fact, this happens quite often :-)

[JVanB]

The FUNCTION line is a big can of worms according to the standard. Specifications are supposed to lie before, or somehow to the left of, where they are used, but which specifications are usable in the FUNCTION statement or its NAME= clause? To consider are not only MODULE FUNCTION and IMPORT, but also specifications within the specification-part of the function and PARAMETER and IMPLICIT statements. The standard doesn't really tell you what is allowed and what isn't.

[Steven_L_Intel1]

I am going to have to look at this again and in more detail tomorrow. I am clearly missing some of the fine points of the changes in the language due to submodules, even if submodules are not being used. FortranFan's citation suggests that I am mistaken, and I see that even in my "clarification" I wrote something that was seriously confused.

What I believed at the time is that the code was nonstandard because of the lack of USE or IMPORT. But MODULE FUNCTION changes the behavior in ways I wasn't aware of, and in hindsight this makes sense since MODULE FUNCTION here is new syntax and therefore new rules could apply.

As for RO's wondering about the use of DP in the prefix, I know this has been discussed and the committee agreed that the use of DP in the prefix is interpreted in the context of any use association or IMPORT (or I guess host association) valid in the interface body, It certainly does complicate the compiler's life, but it's been this way since Fortran 90.

[FortranFan]

Steve Lionel (Intel) wrote:

I am going to have to look at this again and in more detail tomorrow. I am clearly missing some of the fine points of the changes in the language due to submodules, ..

Steve,

Something to keep in mind as you look into this further.  This is from J3/10-007 (i.e., WG5/N1826) document on the latest working draft of Fortran 2008 standard, section 12.4.3.3:

[Steven_L_Intel1]

Ok, I finally found the text I wanted, but it took me a long time, partly because I started with the F2015 draft that moved some text around. Quoting F2008:

16.5.1.4 Host Association

A module procedure interface body or derived-type definition has access to entities from its host by host association.

There is also this note:

NOTE 16.8
An interface body that is not a separate interface body accesses by host association only those entities made
accessible by IMPORT statements.

The text FortranFan quotes from early papers is not really helpful, as the final standard could have said something else entirely, but it did give me a clue as to where to look.

So...  To answer the original question: Yes, the code opmkl posted IS standard F2008. However, I would not expect a compiler to accept it if it didn't support submodules, because the declaration of F is as a separate module procedure and would require a submodule to provide the implementation. Intel Fortran is therefore correct in not giving an error for this code.

[OP1]

ok - thanks for the clarification. I will follow up with Cray on this.

[FortranFan]

Steve Lionel (Intel) wrote:

..

The text FortranFan quotes from early papers is not really helpful, as the final standard could have said something else entirely, but it did give me a clue as to where to look.

..

Which text are you referring to?  The one in message #8 or #12?

What constitutes for you the "final standard"?  I have not found anything after WD 1539-1 J3/10-007 (i.e., WG5/N1826) document dated 27 April 2010 besides the corrigenda 1 to 3. 

[Steven_L_Intel1]

I was referring to the TR referenced in post 8. 10-007r1 includes Corrigenda 1 and 2. I first looked at 15-007 to see what the latest text said.