------- Comment #3 from burnus at gcc dot gnu dot org 2007-11-05 17:43 -------
(In reply to comment #2)
> With the Lahey free conformance checker, the example below gives:
> 2278-W: "SOURCE.F90", line 3: Specific procedures (one) and (two) do not
> ensure that generic reference (foo) is unambiguous.
> whilst the original gives:
> Encountered 0 errors, 0 warnings
> Thus confirming ifort's version.
> Thus, I would be inclined to confirm the original but to let a careful reading
> of the standard decide the example below.
Regarding the example of comment 0, the following is the relevant part from the
Fortran 2003 standard ("16.2.3 Restrictions on generic declarations"):
"(3) at least one of them shall have both
(a) A nonoptional non-passed-object dummy argument at an effective position
such that either the other procedure has no dummy argument at that effective
position or the dummy argument at that position is distinguishable with it; and
(b) A nonoptional non-passed-object dummy argument whose name is such that
either the other procedure has no dummy argument with that name or the dummy
argument with that name is distinguishable with it.
[(c)] Further, the dummy argument that disambiguates by position shall either
be the same as or occur earlier in the argument list than the one that
disambiguates by name."
Regarding (a): The argument at the second effective position is non-optional
and is once a procedure (a complex-returning function) and once a complex
number.
Regarding (b) this argument has the name "z_2=" which is not ambiguous as the
constrain which I labelled "(c)" is satisfied.
Now, the question is whether a function and a non-function are distinguishable.
"Two dummy arguments are distinguishable if neither is a subroutine and neither
is TKR compatible (5.1.1.2) with the other."
This sounds as if this is not the case as the function returns a "COMPLEX(4)"
scalar and the other argument is also a COMPLEX(4) scalar. I also read this as
if a subroutine-argument is non-distinguishable with any other argument.
I think the logic is that for
external foo
real foo
real bar
the scalar-real-function w/ implicit interface "foo" and the scalar real "bar"
are indistinguishable and that
external proc
states that "proc" is either a function or a subroutine and thus "proc" is
indistinguishable with any other subroutine/function/variable.
(As the dummy has an explicit interface, the actual argument has to match and
thus one could distinguish functions from variables; seemingly the standard
avoided to distinguish between implicit interfaces and explicit interfaces and
of discussing the distinguishability of dummy procedures (which checking would
be nested).)
In conclusion, my example of comment 0 is wrong.
Regarding the example to comp.lang.fortran:
z_1, z_2, z_3, f_func, z_tol_r, z_tol_i, [max_iterations,] [f_1,] [f_2,] [f_3,]
[relative_tol]
complex(8),complex(8),complex(8),complex(8),real(8),real(8),[integer,]
[complex(8),][complex(8),][complex(8),][logical]
z_1, z_2, f_func, z_tol_r, z_tol_i, [max_iterations,] [f_1,] [f_2,] [f_3,]
[relative_tol]
complex(8),complex(8),complex(8),real(8),real(8),[integer,]
[complex(8),][complex(8),][complex(8),][logical]
Here, the first 3 arguments are indistinguishable (scalar complex(8)
function/variables), but the 4th argument is different: complex(8) function and
real(8) variable. Thus (a) applies.
Regarding (b): Yes, the non-optional "z_3=" has a different (unique) name.
However, I don't think the following applies:
"Further, the dummy argument that disambiguates by position shall either be the
same as or occur earlier in the argument list than the one that disambiguates
by name."
Here, the name argument (3rd, "z_3") is earlier than position argument (4th,
real(8)/complex(8)).
(For obvious reasons "(1)" and "(2)" in the standard do not apply.)
Thus I would conclude that both test programs are invalid, and are properly
rejected by gfortran and NAG f95. (But I might be convinced otherwise; I will
write to c.l.f and wait for the response.)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33997
