Compile error with generic procedures

[John_Young]

Hi,

Since moving to intel fortran version 13 (linux), we have been getting some compile time errors related to generic procedure resolution.  We see the following error.  Version 12 does not seem to give this error nor do other non-intel fortran compilers I've checked with.  I've copied a short test case. Any help would be appreciated.

error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature.

Thanks,

John

!============================================
module globals
  public
 
  integer, parameter :: sg = kind(1.0)   ! single precision
  integer, parameter :: db = kind(1.0d0) ! double precision

  type :: Complex16Vec
  end type
 
  type :: Real8Vec
  end type
 
end module globals
!==============================================
module ComplexVectorOperationsDP
    use globals, VectorType => Complex16Vec
    private
    
    interface Vec2Norm ; module procedure Sub_Vec2Norm; end interface

    public :: Vec2Norm

    contains

      subroutine Sub_Vec2Norm(iVector, VecTwoNorm)
        implicit none
                
        type(VectorType), intent(in) :: iVector
        real(kind=db), intent(out) :: VecTwoNorm
      
        VecTwoNorm = 0._db
        
      end subroutine Sub_Vec2Norm
   
end module ComplexVectorOperationsDP
!================================================
module RealVectorOperationsDP
    use globals, VectorType => Real8Vec
    private
    
    public :: Vec2Norm

    interface Vec2Norm ; module procedure Sub_Vec2Norm; end interface

    contains

      subroutine Sub_Vec2Norm(iVector, VecTwoNorm)
        implicit none
                
        type(VectorType), intent(in) :: iVector
        real(kind=db), intent(out) :: VecTwoNorm
      
        VecTwoNorm = 0._db
        
      end subroutine Sub_Vec2Norm
   
end module RealVectorOperationsDP
!=================================================
program test
  use globals

  ! If only one of the two 'use' modules below are used, ifort 13.0.0.079 (linux) compiles fine.
  ! If both are included, ifort 13.0.0.079 (linux) give compile errors.
  ! ifort 12.1.0.233 compiles fine for both cases.
  use ComplexVectorOperationsDP    
  use RealVectorOperationsDP       
  implicit none
 
  real(db) tmpNorm
  integer :: im

  type(Complex16Vec) :: abc

  call Vec2Norm(abc, tmpNorm)

end program  test
!===============================================
 

[Izaak_Beekman]

I compiled your code with gfortran, which did not complain. (Usually ifort is more permissive than gfortran, so this surprised me.) Just to clarify, vec2norm is source of the errors. (I think you truncated the error msg)

Is it legal Fortran to declare two interfaces (of the same name) in two separate modules and then use both of them without renaming them in a third? My intuition says no, and that you shouldn't be allowed to achieve overloading like this, but I am not familiar enough with the standard to comment definitively.

[John_Young]

Hi Izaak,

Thank you for looking at this error.  I cannot answer your question with 100% certainty whether it is legal fortran or not, but we have been using this technique for a long time and this is the first time any compiler has ever complained.  My feeling is that it is valid, but I will ask some people who are more knowledgeabe with the Fortran standard to see if it is valid or not. 

Thanks,

John

[Kevin_D_Intel]

Seems like something may have intentionally changed with the compiler's treatment of this code. I thought it might be able to distinguish the two procedures but even our latest release (14.0 compiler) issues the same error. I'll make some inquiries and report back when I know more.

[Kevin_D_Intel]

I may be wrong, but I escalated this to Development (under the internal tracking id below) because I believe this is a defect.

The error appears tied to each module’s variable renaming to the local name VectorType. The same local name has association with each interface and this confuses the interface choice in the main program and generates the error. I do not whether this is a usable work around in your original app or not; however, when only one module renames its unique type to VectorType the example compiles.

I will keep you updated about a possible fix and any other work around I hear about from Development.

(Internal tracking id: DPD200249459)

(Resolution Update on 05/30/2014): This defect is fixed in the Intel® Fortran Composer XE 2013 SP1 Update 3 release (Version 14.0.3.174 Build 20140422 - Linux)

[John_Young]

Kevin,

Thanks for your attention to this matter.

[Kevin_D_Intel]

Development has a fix for this issue. It missed the deadline for the upcoming Composer XE 2013 SP1 Update 2 but it is expected to be in Update 3 (tentatively in the mid-Spring timeframe).

I will update this thread again when the fix is available.

[Kevin_D_Intel]

This defect is fixed in the Intel® Fortran Composer XE 2013 SP1 Update 3 Release (Version 14.0.3.174 Build 20140422 - Linux) now available from our Intel Registration Center.