a compiler error not caught by PVF 12.10

Hi, everyone,

I tried to compile the source code below where an IMPORT statement is ignored in the second abstract interface area on purpose.

The Intel Visual Fortran compiler 2013 issues a compiler error saying that error #8169: The specified interface is not declared @ the second abstract interface, while the same source code can be compiled using the Portland Visual Fortran 12.10.

Based on the outcome generated by PVF 12.10 above, I am wondering if PVF has accepted the convention of Fortran 2008 already. Can anyone help me out with this question?

Thanks,
Li



MODULE toolbox                                                             
    IMPLICIT NONE                            
    REAL, DIMENSION(:), POINTER :: fvec1p, fvec2p                   
    ABSTRACT INTERFACE                                      
        FUNCTION functions_system(x) RESULT(y)              
        IMPLICIT NONE                                       
        REAL, DIMENSION(:), INTENT(IN) :: x                 
        REAL, DIMENSION(SIZE(x)) :: y                       
        END FUNCTION                                        
    END INTERFACE                                           
    
    ABSTRACT INTERFACE                                      
        FUNCTION middle_function_template(x,fvec_p,proc_p) RESULT(y)  
        ! IMPORT                    !<---------------- COMMENT OUT ON PURPOSE 
        IMPLICIT NONE                                       
        REAL, DIMENSION(:), INTENT(IN) :: x                 
        REAL, DIMENSION(:), POINTER :: fvec_p               
        PROCEDURE(functions_system), POINTER :: proc_p       ! <----- the error line caught by IVF 
        REAL :: y                                           
        END FUNCTION                                        
    END INTERFACE                                           
    
    PROCEDURE(functions_system), POINTER :: proc1p, proc2p  
CONTAINS                                                    
    FUNCTION func_system1(x) RESULT(y)                                 
        IMPLICIT NONE                                           
        REAL, DIMENSION(:), INTENT(IN) :: x   
        REAL, DIMENSION(size(x)) :: y                            
        y(1)=x(1)                                      
        y(2)=x(2)                                  
    END FUNCTION func_system1
    
    ! the major program returns the normalization of
    ! a given vector 
    SUBROUTINE MajorSolver(ans,x,fvec_p,proc_p)
        IMPLICIT NONE
        REAL, DIMENSION(:), POINTER :: ans
        REAL, DIMENSION(:), INTENT(IN) :: x
        REAL, DIMENSION(:), POINTER :: fvec_p
        PROCEDURE(functions_system), POINTER :: proc_p
        PROCEDURE(middle_function_template), POINTER :: proc3p
        REAL, DIMENSION(SIZE(x)), TARGET :: y ! kept for other use
        REAL :: z
        fvec_p=>y                                           
        proc3p=>MiddleFunction								
        z=AssistantSolver(x,proc3p,fvec_p,proc_p)           
        ans=fvec_p**2/z                                     
    END SUBROUTINE MajorSolver                              
    
    FUNCTION AssistantSolver(x,func,fvec_p,proc_p)          
        IMPLICIT NONE                                       
        REAL, DIMENSION(:), INTENT(IN) :: x                 
        procedure(middle_function_template), pointer :: func
        REAL, DIMENSION(:), POINTER :: fvec_p               
        PROCEDURE(functions_system), POINTER :: proc_p      
        REAL :: AssistantSolver                             
        AssistantSolver=func(x,fvec_p,proc_p)               
    END FUNCTION AssistantSolver       
    
    ! return the innder product of the vector proc_p evaluated at x
    FUNCTION MiddleFunction(x,fvec_p,proc_p)                
        IMPLICIT NONE                                       
        REAL, DIMENSION(:), INTENT(IN) :: x                 
        REAL, DIMENSION(:), POINTER :: fvec_p               
        PROCEDURE(functions_system), POINTER :: proc_p
        REAL :: MiddleFunction
        fvec_p=proc_p(x)
        MiddleFunction=dot_product(fvec_p,fvec_p)
    END FUNCTION                       
END MODULE toolbox

PROGRAM main
USE toolbox
IMPLICIT NONE
REAL, DIMENSION(:), POINTER :: ans
REAL :: data2(2)
data2=[1.,2.]                                               
proc1p=>func_system1                                        
allocate(ans(size(data2)))                                  
call MajorSolver(ans,data2,fvec1p,proc1p)                   
write(*,'(a,2(f7.3))'),'Equations system 1: Ans= ',ans
nullify(ans,proc1p)
END PROGRAM main

Hi Li,

I’ve asked one of our engineers to look into this. He’s trying to find case and versus as to why this is an error. Intel and NAG flag it, but PGI and Gfortran do not.

Does the code run correctly?

  • Mat

Hi Mat,

Yes, the code runs correctly in PVF. Thanks for the reply.

Li

Hi Li,

Our engineer thinks that this should be flagged as an error so I added a problem report (TPR#19504).

Though, he’s wondering why you think this would be ok under F2008.

His reponse:

I am curious what the user meant by “F2008 conventions” because I did not see anything in the language spec that would indicate F2008 allowing the user to not specify IMPORT in this case.

I did see the following difference in the spec for host association, but I don’t believe it applies in this case:

F2003 Host association (from section 16.4.1.3, first paragraph, Host association page 441 F2003 language spec):

An interface body has access via host association to the named entities from its host that are made accessible by IMPORT statements in the interface body.

F2008 Host association (from 16.5.1.4, first paragraph, Host association page 443 in F2008 language spec):

An interface body interface that is not a separate interface body has access via host association to the named entities from its host that are made accessible by IMPORT statements in the interface body.

I wonder if the user is referring to the “separate interface body” exception. However, I don’t think this applies based on the following definition of “separate interface body”:

(from section 12.4.3.2 Interface block, 4th note on page 280 of F2008 language spec)

A separate interface body is an interface body whose initial statement contains the keyword MODULE….

Based on the above definition, the exception doesn’t apply to the user’s code, so I believe IMPORT is required under both F2003 and F2008 conventions. I’m curious what the user meant by “F2008 conventions” in case I’m just missing something here. Please ask him for a clarification.

  • Mat

Hi Mat,
I mean the second interface body can have access to the first interface body via host association by IMPORT because both of the interface bodies reside in the same module. Please correct me if my understanding is wrong. Thanks.
Li

TPR 19504 ABSTRACT INTERFACE problem has been corrected in the current
13.10 release.

thanks,
dave