Same signature procedures in interface

In the following code, the two subroutines aaa1 and aaa2 have the same signature and the compiler should detect this and generate an error message but it doesn't.

module xxx

   interface aaa
      module procedure aaa1
      module procedure aaa2
   end interface

contains

   subroutine aaa1(a, b, c)
      real :: a, b(2), c
      c = a + b(1)
   end subroutine aaa1

   subroutine aaa2(b, a, c)
      real :: b(2), a, c
      c = a + b(1)
   end subroutine aaa2

end module xxx

Both NAG and gfortran compilers correctly report the error in the above.

FTN95 should generate this error:

error 435 - Specific procedure AAA2 of type SUBROUTINE is too similar to AAA1 of type SUBROUTINE for overload AAA in module XXX. The arguments are too similar.

I know they [u:702f5f2791]look[/u:702f5f2791] like they have different signatures, but they don't. I can demonstrate the signatures are the same, since the following code works:

program main
   use xxx

   real :: s, w(4)

   w = 0.0
   
   call aaa1(w(1), w(3), s)
   call aaa2(w(1), w(3), s)
   
end program main

The compiler seems to know something is wrong though, because the following doesn't compile, but the error message is misleading.

error 418 - No matching specific procedure for generic overloaded name AAA

program main2
   use xxx

   real :: s, w(4)

   w = 0.0
   
   call aaa(w(1), w(3), s)
 
end program main2

I will make a note of this.

I have had a look at this but I am reluctant to change FTN95 at this point.

FTN95 and Lahey do behave differently from gFortran and NAG. FTN95 and Lahey report an error when you compile a subprogram that uses the generic rather than when you compile the module.

However both FTN95 and Lahey allow you to use the generic when you call it in a certain way (when you pass the array by its name).

Although this behaviour should strictly be regarded as an extension to the Standard, if I add the constraint now it might unwittingly break someone's code.

Quoted from PaulLaidler

FTN95 and Lahey do behave differently from gFortran and NAG. FTN95 and Lahey report an error when you compile a subprogram that uses the generic rather than when you compile the module.

As long as there is an error generated there is no problem with this approach.

Quoted from PaulLaidler

However both FTN95 and Lahey allow you to use the generic when you call it in a certain way (when you pass the array by its name).

Hmmm... If I had used different names for the dummy arguments in the subroutines, there wouldn't be an error since one could use the NAME of the argument to distinguish between the two cases.

However, in the example, I deliberately chose the same names so that it should be impossibe to ever make a valid call using the generic interface.

Could you post a calling sequence to show what you mean?

Using your module, the following code produces self-consistent results that are the same for FTN95 and Lahey.

program main 
   use xxx 
   integer :: s, w(4) 
   call aaa(w(1), w, s)
   call aaa(w, w(4), s)
end program main 

Given that one normally gets an error condition, I am happy for now to treat this usage as an extension to the Standard.

Well I'm confused. 😃

When I try your code with my module, I get the following Error messages (one for each call):

D:\xxx\anon.F90(25) : error 418 - No matching specific procedure for generic overloaded name AAA D:\xxx\anon.F90(26) : error 418 - No matching specific procedure for generic overloaded name AAA

If I then 'correct' the declarations in your code to match those in the interface (changing Integer to Real), the program seems to compile OK.

It calls aaa1 for the first call and aaa2 for the second call. I can't see why though!

I can see what you're doing now. Since F90 you shouldn't distinguish between an actual argument W(1) and W when matching to a dummy array argument. (I think this requirement comes from a desire to be compatible with F77 codes).

So I would expect a compile error here.

No problem though. Just keep this as an extension to what is in the Fortran standard.