In the following program, generic procedure "foo" can be distinguished between two procedure "foo1" and "foo2" by keywords of arguments. But gfortran cannot compile this source code and output the same message twice. I think it is wrong behavior. $ cat test.f90 module m1 implicit none interface foo module procedure foo1 end interface contains subroutine foo1(j) integer :: j end subroutine end module module m2 implicit none interface foo module procedure foo2 end interface contains subroutine foo2(i) integer :: i end subroutine end module program test use m1 use m2 implicit none call foo(j=3) end program $ gfortran --version GNU Fortran 95 (GCC) 4.2.0 20060129 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. GNU Fortran comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of GNU Fortran under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING $ gfortran test.f90 In file test.f90:24 use m1 1 Error: Ambiguous interfaces 'foo1' and 'foo2' in generic interface 'foo' at (1) In file test.f90:24 use m1 1 Error: Ambiguous interfaces 'foo1' and 'foo2' in generic interface 'foo' at (1)
Intel agrees with gfortran: fortcom: Error: foofoo.f90, line 25: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-spec. [FOO2] use m2 ------^ fortcom: Error: foofoo.f90, line 24: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-spec. [FOO1] use m1 ------^ compilation aborted for foofoo.f90 (code 1) Also Lahey checker agrees: Checking file SOURCE.F90. Checking program unit M1 at line 1. Checking program unit M2 at line 12. Checking program unit TEST at line 23. Line 25, file SOURCE.F90 use m2 | FATAL -- The arguments for procedures (FOO2) and (FOO1) allow references to the generic procedure to be ambiguous (see "Procedure Interfaces" in your Fortran 90 language reference). Encountered 1 error, 0 warnings in file SOURCE.F90.
(In reply to comment #1) Intel does NOT agree with gfortran. I think such discussion is not fruitful. $ ifort --version ifort (IFORT) 9.0 20060222 Copyright (C) 1985-2006 Intel Corporation. All rights reserved. $ ifort test.f90 fortcom: Warning: test.f90, line 25: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name. [FOO2] use m2 ------^
Iguchi-san, You are correct. The reference to foo with an integer argument is disambiguated by the use of the keyword. The only compiler that I have found that handles this correctly is DF5.0/6.0. Domo arigato gozaimasu
I only have access to the free versions of Intel version 8.0 and version 9.0 and both gave aborted compilation on the test case for ambiguity. Next step is to check the standards, which I presume Paul has done. :) I see that the Intel compiler Iguchi has gives a warning. Paul only found one other compiler that accepts it. Perhaps this behavior is an extension to the standard?
Looking at the standard: Looking in the F95 Standard: " NOTE 12.4 The dummy argument names may be different because the name of a dummy argument is not a characteristic. " Also, allowing the use of a keyword to resolve the ambigity conflicts with the optional use of keywords. In the test case given you can not call foo without a keyword which would make the keyword use mandatory which the standard says is optional. I also checked one of my Fortran 90 books. It says that the type and number of arguments are used to determine the function or procedure to call. It does not say anything about keywords. All the examples show disambiguation by argument type. Note: I am not a standards authority, this is just all I could find.
I was asked about this yesterday. I see my comments didn't make it here, so I'll try putting them in myself with this new account. (No, I can't monitor bug reports with any regularity; I can't even really keep up with the mailing list.) This is not a bug. The code is nonstandard and the compiler is acting exactly as specified by the standard. Actualy, even the summary line is wrong, and in a way that illustrates the misunderstanding here. The compiler is not rejecting the call; the error is at the USE statements, before the call even comes into play. See 14.1.2.3 of the f95 standard. That's where the relevant material is. Some cases of disambiguation are tricky and can't be reasoned out without checking the exact words of the standard (just because a human can see how to disambiguate something, that doesn't mean it is standard conforming, so you have to actually check the standard rather than figure out whether you could disambiguate it). But this case is trivial, and the whole point is the misunderstanding illustrated by the summary line. A generic is required to be unambigous under *ALL* possible calls. It isn't even relevant what particular calls are made. An illegal generic is illegal even if it isn't called at all. In particular, a generic is required to be unambiguous under both keyword and positional forms. There is even a tricky condition relating to mixed cases, but this example doesn't get into that. This example is trivially ambiguous in positional form. Again, it doesn't matter that there are no such positional calls; the generic itself is what is illegal - not the calls. For the exact citation, see the word "both" on line 24 of page 277 of f95. I note as an aside that even though the OP noted that the Intel compiler "disagreed" with gfortran, the data he posted does not support that statement. The Intel compiler also caught the problem, the only distinction being that at least one version appears to treat it as a warning instead of a fatal error. IN any case, regardless of what any other compiler might do, the code is nonstandard. I also note that this kind of extension is exceedingly dangerous to count on - more so than many extensions - because it has high odds of having conflicts with future enhaancements to the standard. Generic disambiguation has subtle rules and there are many (sometimes conflicting) proposals to enhance them. I think this bug should be marked as "invalid", but I'll leave that call to others, as you could consider it an enhancement request for an extension. I'd advise against such an extension, but that's not my call.
This is not a compiler bug.