Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
New Contributor I
95 Views

Unresolved/ambiguous interfaces for generic overloaded procedure

I have a program that uses an overloaded procedure, an example of which is given below. The procedure compiles without error in IVF 19.0.2.190. Although I use Intel Fortran for a majority of my needs, we have a few applications that require gcc/gfortran as well. The example module below generates an error with gfortran when compiled with the arguments "gfortran -c". I am unable to determine what the error is in the example below. I would appreciate any help on this. If gfortran is in error, then I will find a workaround (e.g. not using an overloaded routine in gfortran). However, if this is somehow incorrect according to the Fortran standard, then I would rather have the correct routine for all applications.

Error in gfortran

C:\Temp\gfortran -c test_generic_string.f90

test_generic_string.f90:31:2:

   function olf3(a, b) result (check)
  1
test_generic_string.f90:44:2:

   function olf4(b, a) result (check)
  2
Error: Ambiguous interfaces in generic interface 'olf' for 'olf3' at (1) and 'olf4' at (2)

Original code

module overload

  ! check whether two strings are the same
  
  implicit none

  interface olf
     module procedure olf1, olf2, olf3, olf4
  end interface olf

contains

  function olf1(a, b) result (check)
    logical :: check
    character(len = *) :: a, b
    ! both arguments are scalar strings
    check = (trim(adjustl(a)) == trim(adjustl(b)))
  end function olf1

  function olf2(a, b) result (check)
    logical :: check
    character(len = *) :: a(:), b(:)
    ! both arguments are vector strings
    integer :: n, i
    n = size(a)
    check = .false.
    if (size(b) /= n) return
    do i = 1,n
       if (trim(adjustl(a(i))) /= trim(adjustl(b(i)))) return
    end do
    check = .true.
  end function olf2

  function olf3(a, b) result (check)
    logical :: check
    character(len = *) :: b
    character(len = *), dimension(:) :: a
    ! first argument is a vector of strings to be tested against
    ! second argument, which is a scalar
    integer :: n, i
    n = size(a)
    check = .false.
    do i = 1,n
       if (trim(adjustl(a(i))) /= trim(adjustl(b))) return
    end do
    check = .true.
  end function olf3

  function olf4(b, a) result (check)
    logical :: check
    character(len = *) :: b
    character(len = *), dimension(:) :: a
    ! second argument is a vector of strings to be tested against
    ! first argument, which is a scalar
    integer :: n, i
    n = size(a)
    check = .false.
    do i = 1,n
       if (trim(adjustl(a(i))) /= trim(adjustl(b))) return
    end do
    check = .true.
  end function olf4

end module overload

 

0 Kudos
3 Replies
Highlighted
Black Belt
95 Views

The argument lists of olf3 and olf4 differ only in the  order in which the sets of arguments appear. Consider what the compiler should do if, in a segment of code that USEs the module, there is a reference to the overloaded procedure name with keyword arguments:

     check = olf(a = 'str1', b = ['str2', 'str3'])

Is this to be interpreted as

     check = olf4('str1', ['str2', 'str3'])

or as

     check = olf3(['str2', 'str3'], 'str1')

? Do you see the ambiguity now?

Your code is such that either interpretation will lead to the same function result, but that will not happen in general, and we do not expect the compiler to compare the executable statements in olf3 to those of olf4 to resolve such ambiguities.

0 Kudos
Highlighted
Honored Contributor I
95 Views

Given the facility in Fortran with keyword names [ =olf(a=..,b=..) ] in procedure argument correspondence, your specified interfaces for olf3 and olf4 are ambiguous.  Intel Fortran has a bug, I think, in not identifying this ambiguity - I believe, though I'm uncertain at the moment, the standard requires a processor to diagnose this.  You may want to submit a support request to get feedback from Intel support.

An immediate resolution will be to rename the dummy argument in one of the 2 above functions. 

0 Kudos
Highlighted
New Contributor I
95 Views

Thanks for the useful and educational responses, @FortranFan and @mecej4. It had not occurred to me that keyword names were the cause of the ambiguity. I renamed the variables a and b in olf4 to aa and bb. Now gfortran compiles without error. IVF, ofcourse, did not have a problem as I stated. I will report the error to Intel support.

 

0 Kudos