Fortran - ambiguous INTREFACE

Author

ambiguous INTREFACE

Steven G. Kargl

2005-09-22, 6:58 pm

While attempting to compile a popular library that
can be obtained via the internet, gfortran died with
a segmentation fault. A reduced version of the
problem is

module y
private f

interface ambiguous
module procedure f
end interface

contains
real function f(a)
real a
f = a
end function
end module y

module z
use y

interface ambiguous
module procedure f
end interface

contains
real function f(a)
real a
f = a
end function
end module z

If I run this through Lahey's code checking facility, I get

Compiling program unit y at line 1:
Compiling program unit z at line 22:
2278-W: "SOURCE.F90", line 27: Specific procedures (f) and (f) do
not ensure that generic reference (ambiguous) is unambiguous.
Encountered 0 errors, 1 warning, 0 informations in file SOURCE.F90.
Compiling file SOURCE.F90.

Perhaps, I'm misinterpreting C1209 from the F2003 draft I have.

C1209 (R1206) A procedure-name shall not specify a procedure that is
specified previously in any procedure-stmt in any accessible interface
with the same generic identifier.

Shouldn't this mean the code is illegal?

--
Steve
http://troutmask.apl.washington.edu/~kargl/

[JvO]

2005-09-22, 6:58 pm

Indeed, the code is illegal.

G95 says:

In file unti2.f95:19

module procedure f
1
Error: Ambiguous interfaces 'f' and 'f' in generic interface
'ambiguous' at (1)

[JvO]

Richard E Maine

2005-09-22, 6:58 pm

In article <dgunqm$374$1@gnus01.u.washington.edu>,
kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:

[code elided]

> 2278-W: "SOURCE.F90", line 27: Specific procedures (f) and (f) do
> not ensure that generic reference (ambiguous) is unambiguous.
> Encountered 0 errors, 1 warning, 0 informations in file SOURCE.F90.

> Perhaps, I'm misinterpreting C1209 from the F2003 draft I have.
>
> C1209 (R1206) A procedure-name shall not specify a procedure that is
> specified previously in any procedure-stmt in any accessible interface
> with the same generic identifier.
>
> Shouldn't this mean the code is illegal?

No. The code is illegal, but that constraint has nothing to do with it.
That constraint is specifically about specifying the *SAME* procedure
twice. The code here doesn't "specify a procedure that is specified
previously...". What was specified previously was a different procedure.
The fact that the two procedures happen to have the same name... and
indeed have identical source code... does not make them the "same"
procedure. They are two different procedures that happen to look an
awful lot alike.

The code is illegal because it violates the conditions intended to
ensure ambiguity. That would be the stuff in 14.1.2.3. There are cases
where the application of those rules is tricky and gives non-intuitive
results, where a human can see that there will be no ambiguity, but the
code doesn't conform to the (conservative) rules of 14.1.2.3. But this
case isn't one of those, being about as obviously ambiguous as one could
possibly imagine.

So yes the code is illegal, but I don't understand the implications
behind your question in that you seem to be implying that this means
there is something wrong with the Lahey compiler in this regard. The
restrictions in 14.1.2.3 are not constraints, so a compiler is not
required to diagnose them (but it would sure be nice, and to my
knowledge all compilers do, or at least attempt to). But it looks to me
like the Lahey compiler did diagnose it. Are you complaining that it is
a warning instead of an error? Looks to me like the Lahey compiler
probably allows it as an extension, while warning about it. That's not
obviously unreasonable.

Oh. I just noticed that your citations are from f2003 instead of f90. So
instead of 14.1.2.3, look in 16.2.3 of f2003 (and the elaboration in
C.11.2).

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Steven G. Kargl

2005-09-22, 6:58 pm

In article <nospam-395261.10545422092005@news.supernews.com>,
Richard E Maine <nospam@see.signature> writes:
> In article <dgunqm$374$1@gnus01.u.washington.edu>,
> kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:
>
> [code elided]
>
>
>
> No. The code is illegal, but that constraint has nothing to do with it.
> That constraint is specifically about specifying the *SAME* procedure
> twice. The code here doesn't "specify a procedure that is specified
> previously...". What was specified previously was a different procedure.
> The fact that the two procedures happen to have the same name... and
> indeed have identical source code... does not make them the "same"
> procedure. They are two different procedures that happen to look an
> awful lot alike.
>

(Discussion of 14.1.2.3 elided)

> So yes the code is illegal, but I don't understand the implications
> behind your question in that you seem to be implying that this means
> there is something wrong with the Lahey compiler in this regard.

I am implying nothing about Lahey. I'm trying to understand what I
need to do to make gfortran work properly. Lahey happens to have a
very nice web-based Fortran 95 conformance checking tool, which flags
the code with a warning. I then went to the F2003 draft and started
to thumb through the section on the interface construct. The simliarity
in the code of the two modules led me to misinterpret C1209.

Note, I also run code through NAG's compiler when I'm trying to decipher
what the Standard says. The laptop is sitting in a briefcase; otherwise,
I would have also checked what NAG reports.

> The restrictions in 14.1.2.3 are not constraints, so a compiler is not
> required to diagnose them (but it would sure be nice, and to my
> knowledge all compilers do, or at least attempt to). But it looks to me
> like the Lahey compiler did diagnose it. Are you complaining that it is
> a warning instead of an error? Looks to me like the Lahey compiler
> probably allows it as an extension, while warning about it. That's not
> obviously unreasonable.

No, I not complaining about Lahey. OTOH, I would be interested
to know how Lahey (or any other compiler) could resolve the
ambiguity. The example code I posted was distilled from a well-known
library.

> Oh. I just noticed that your citations are from f2003 instead of f90. So
> instead of 14.1.2.3, look in 16.2.3 of f2003 (and the elaboration in
> C.11.2).

As always, I found 16.2.3 about 20 minutes after my initial post. :-)
Of course, it's going to take me several hours to actually understand
what 16.2.3 says.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Richard E Maine

2005-09-22, 6:58 pm

In article <dgusqr$73o$1@gnus01.u.washington.edu>,
kargl@troutmask.apl.washington.edu (Steven G. Kargl) wrote:

> As always, I found 16.2.3 about 20 minutes after my initial post. :-)
> Of course, it's going to take me several hours to actually understand
> what 16.2.3 says.

Only several hours? Wow, you are good! I'm sure it took me longer than
that. :-)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

James Van Buskirk

2005-09-22, 6:58 pm

"Steven G. Kargl" <kargl@troutmask.apl.washington.edu> wrote in message
news:dgusqr$73o$1@gnus01.u.washington.edu...

> No, I not complaining about Lahey. OTOH, I would be interested
> to know how Lahey (or any other compiler) could resolve the
> ambiguity. The example code I posted was distilled from a well-known
> library.

My experience is that Lahey, at least in older versions, would
resolve the ambiguity by substituting the first specific
function that matched the lame 'TKR' requirements of the
invocation. For example if an actual argument was a function
taking a single default real input with a default logical
result, but it tried matching up another procedure with
the corresponding dummy argument being instead a subroutine
taking a rank-one default integer assumed shape array first,
well then...

Would you believe that I'm not overly fond of Lahey's
behavior in this context nor indeed the standard's TKR
method of generic procedure resolution? CVF at least
would try to build data structures so that you had a
fighting chance to match up function signatures across
explicit interfaces, even though the standard doesn't
mandate this nor even make it possible in all cases, and
you could mess up CVF pretty easily by intentionally
making it hard to compare function signatures, but at
least it gave you some kind of safety net. CVF didn't
seem to catch the current problem for some reason,
however.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[JvO]

2005-09-23, 7:58 am

Richard E Maine schreef:

[stuff elided]

>
[color=darkred]
> The code is illegal because it violates the conditions intended to
> ensure ambiguity. That would be the stuff in 14.1.2.3. There are cases
!^^^^^^^^^^^^^^^^^^^^ ??
I'd prefer the Standard to unambiguous :-)

> where the application of those rules is tricky and gives non-intuitive
> results, where a human can see that there will be no ambiguity, but the
> code doesn't conform to the (conservative) rules of 14.1.2.3. But this
> case isn't one of those, being about as obviously ambiguous as one could
> possibly imagine.

Richard E Maine

2005-09-23, 7:00 pm

In article <1127467289.646445.58350@g43g2000cwa.googlegroups.com>,
"[JvO]" <jvo_36@hotmail.com> wrote:

> Richard E Maine schreef:
>
> !^^^^^^^^^^^^^^^^^^^^ ??
> I'd prefer the Standard to unambiguous :-)

But then us "language lawyers" would be out of work. :-)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Sponsored Links