Generic interface problem with gfortran

[Richard Weed]

I have an issue compiling some code with gfortran that Intel 14 through 17 and PGI 17.4 accept with no problem. This occurs will all the gfortrans
I've tried >= 4.8. I have a couple of functions that will unroll 2D and
3D array indicies into a "multi-index" (ie the equivalent address in a
1D array if you did a RESHAPE on the 2D or 3D array). The issue I think
is with some optional arguments I have in the function arg. lists that gfortran
is not handleing properly. The function signatures etc. look like the
following

Module arrayUtils

Interface multiIndex
Module Procedure multiIndex2D
Module Procedure multiIndex3D
End Interface

Enum, BIND(C)
ENUMERATOR :: dummy
End Enum

Integer, parameter :: C_ENUM = KIND(dummy)

! 2D function signature

Pure Function multiIndex2D(i, j, irows, jcols, order, index_base) &
Result(mindex)

! Return the multi-index for 2D array given i,j

Implicit NONE

Integer, Intent(IN) :: i, j, irows, jcols
Integer(C_ENUM), Intent(IN), OPTIONAL :: order
Integer, Intent(IN), OPTIONAL :: index_base
Integer :: mindex
.
.
.
End Function

Pure Function multiIndex3D(i, j, k, irows, jcols, kcols, order, &
index_base) Result(mindex)

! Return the multi-index for an 3D array given i,j, k

Implicit NONE

Integer, Intent(IN) :: i, j, k, irows, jcols, kcols
Integer(C_ENUM), Intent(IN), OPTIONAL :: order
Integer, Intent(IN), OPTIONAL :: index_base

Integer :: mindex

End Function

End Module

So, is this a bug in gfortran, or are both Intel and PGI wrong. I would think
that the fact that (positionally) the 3D function has two extra non-optional
dummy arguments before you get to the optional ones would make its
signature unique from the 2D function. Also, as an aside, I think it would
have been nice if the Standards folks had included a C_ENUM type in the
C-Interop types from ISO_C_BINDING. I know its probably a C_INT but for
portability etc. having an explicit C_ENUM would help. I'm using ENUMs for
a lot of things these days since I find it a little easier than typing a bunch
of INTEGER, PARAMETER statements.

RW

[paul.rich...@gmail.com]

To inform other users, the error message from gfortran is:

Error: Ambiguous interfaces in generic interface 'multiindex' for ‘multiindex2d’ at (1) and ‘multiindex3d’ at (2)

How is the processor supposed to resolve:

use arrayUtils
integer :: ans

ans = multiIndex (1, 2, 3, 4, 5, 6)

end

???? (Thanks to Dominique d'Humieres for pointing that out.

Paul

[Richard Weed]

Paul

Thanks. I should have posted the error message. I guess the question is still
why do both Intel and PGI appear to think the code is O.K. (and by inference standard conforming) but gfortran does not. I can see that you could make a case for it being either way (correct or ambiguous). Since I do most of my development with Intel, I just assumed it was correct. Hopefully, someone from the Standards Committee can chime in and clear this up.

RW

[Dick Hendrickson]

Isn't it ambiguous if Integer(C_ENUM) is the same kind as plain old
Integer? Otherwise, doesn't the difference in kinds resolve the reference?

Dick Hendrickson

[FortranFan]

On Saturday, October 7, 2017 at 2:42:41 PM UTC-4, Richard Weed wrote:

> .. I guess the question is still
> why do both Intel and PGI appear to think the code is O.K. (and by inference standard conforming) but gfortran does not. I can see that you could make a case for it being either way (correct or ambiguous). Since I do most of my development with Intel, I just assumed it was correct. Hopefully, someone from the Standards Committee can chime in and clear this up. ..


No need for the standards committee to chime in on this, the problem is clear enough - there can indeed be an ambiguous generic interface if the INTEGER kind of the C interoperable type with the companion C processor is the same as that of default INTEGER. I don't know about PGI but it is the case with Intel Fortran and gfortran that the integer kinds are all the same for the dummy arguments in the example in the original post.

With Intel compiler, it may not flag an error when the module hosting the generic interface is compiled. Instead it will do so when the generic interface is USE'd in a calling program/subprogram in an ambiguous manner e.g., the case presented upthread by Paul Rich Thomas.

So Intel Fortran, in its own way, is handling it alright; if it can disambiguate the function invocation while compiling the calling code, then it does so; if it can't, it raises an error.

gfortran, on the other hand, wishes to be pedantic about this and flags an error at the source itself. Some may like this better.

To each their own..

[Richard Weed]

Thanks all. I don't have time to verify it but it makes perfect sense if as others have noted that the C_ENUM KIND is different from an intrinsic integer
on Intel and PGI that they would accept the code and gfortran wouldn't. To me
this is an example of the standards committee not being specific enough and
giving to much freedom to the compiler writers. I know they assume its not
their job to dictate to the developers how to implement something, its just in
cases like this that the freedom the standard gives to the developers can get in
the way of portability. Guess I'm asking for a little "adult supervision" to insure that any supposedly "standard conforming" compiler will compile code that other self-described "standard conforming" compilers do. Unfortunately, in my humble opinion, the lack of (formerly) J3 and WG5 willingness to hold the developers feet to the fire leads to situations like the ASYNCHRONOUS I/O where only a few (maybe one that I know of) compilers actually implement the feature to do true asynchornous I/O and just default to doing synchronous (as the standard allows them to do). If developers are unwilling or unable to implement a feature as described in the standard to the letter, what is it doing in the standard in the first place.

RW

[Jos Bergervoet]

Unique? Which one do you want if you write:
multiIndex(1,2,3,4,5,6)

It could mean
multiIndex3D(i=1, j=2, k=3, irows=4, jcols=5, kcols=6)

but it could also mean
multiIndex2D(i=1, j=2, irows=3, jcols=4, order=5, index_base=6)

Isn't gfortran correct in reporting "Ambiguous interfaces"?

--
Jos

[Ian Harvey]

On 2017-10-08 05:41, Richard Weed wrote:
> On Saturday, October 7, 2017 at 2:38:02 PM UTC-5, FortranFan wrote:
>> On Saturday, October 7, 2017 at 2:42:41 PM UTC-4, Richard Weed wrote:

...

>> No need for the standards committee to chime in on this, the problem is clear enough - there can indeed be an ambiguous generic interface if the INTEGER kind of the C interoperable type with the companion C processor is the same as that of default INTEGER. I don't know about PGI but it is the case with Intel Fortran and gfortran that the integer kinds are all the same for the dummy arguments in the example in the original post.
>>
>> With Intel compiler, it may not flag an error when the module hosting the generic interface is compiled. Instead it will do so when the generic interface is USE'd in a calling program/subprogram in an ambiguous manner e.g., the case presented upthread by Paul Rich Thomas.
>>
>> So Intel Fortran, in its own way, is handling it alright; if it can disambiguate the function invocation while compiling the calling code, then it does so; if it can't, it raises an error.
>>
>> gfortran, on the other hand, wishes to be pedantic about this and flags an error at the source itself. Some may like this better.
>>
>> To each their own..
>
> Thanks all. I don't have time to verify it but it makes perfect sense if as others have noted that the C_ENUM KIND is different from an intrinsic integer
> on Intel and PGI that they would accept the code and gfortran wouldn't. To me
> this is an example of the standards committee not being specific enough and
> giving to much freedom to the compiler writers. I know they assume its not
> their job to dictate to the developers how to implement something, its just in
> cases like this that the freedom the standard gives to the developers can get in
> the way of portability. Guess I'm asking for a little "adult supervision" to insure that any supposedly "standard conforming" compiler will compile code that other self-described "standard conforming" compilers do. Unfortunately, in my humble opinion, the lack of (formerly) J3 and WG5 willingness to hold the developers feet to the fire leads to situations like the ASYNCHRONOUS I/O where only a few (maybe one that I know of) compilers actually implement the feature to do true asynchornous I/O and just default to doing synchronous (as the standard allows them to do). If developers are unwilling or unable to implement a feature as described in the standard to the letter, what is it doing in the standard in the first place.

There's not really any freedom for this example (unless you are
referring to the freedom given to processors for the kind of C
enumerators).

The requirements on the "distinguishability" of a pair of procedures
that have the same generic name within a scope are specified by
constraint - C1215 in Fortran 2008. The example code in the original
post of this thread, after editing to make it compilable, violates that
constraint within the scope of the arrayUtils module. Processors that
claim conformance (which may require compiling with appropriate flags)
are required to have the capability to detect and report constraint
violations.

So the lack of a diagnostic is just a compiler bug.

(As FortranFan notes, with the Intel compiler, it is easy enough to get
a diagnostic when the generic name is used in a non-distinguishable way,
but the wording of the constraint is stricter than that.

Given how other rules in the language around how generic identifiers can
be extended and how use association works, I can understand why this
case has been overlooked.)

I very much disagree with your view around the value of adding things
like ASYNCHRONOUS to the standard. One of the primary goals of the
standard (the only goal?) is portability of Fortran codes between
processors - the situation where the same code gives the same outputs
across processors, but the different processors may differentiate and
compete amongst themselves by demonstrating superior performance, is
exactly what I want as a user.

[Richard Weed]

Ian

I think you missed my point about ASYNCHRONOUS or maybe I should have worded my statement a little differently. I think ASYNCHRONOUS is a very useful addition to the standard IF everyone implements it as truly ASYNCHRONOUS.
However, looking at things from a purely user perspective what does it gain
for me to make the effort to use ASYNCHRONOUS I/O in my code if only one
or two compilers actually support it. I don't think we do potential users
a favor if we tell them our code is the greatest thing since sliced bread but
you have to run it on a Cray to get all the "superior performance" you can get
from a compiler.

As to how this feature got in the language in the first place when it appears to benefit only a handful of vendors, I'm guessing (having not followed how it got into the standard) it was pushed by one very vocal developer on the committee whose compiler just happened to have a (non-standard) implementation of ASYNCHRONOUS I/O. As to your comment about superior performance, that is secondary to me during the code developement phase of a project. Knowing I can write something that will compile with several different compilers and they will all flag the same error consistently is more important during initial development than raw performance. Unfortunately, I've learned over the years that no one compliler will ever catch all the possible errors or violation of the standard. Also unfortunately, I've learned to not trust compiler developers to interpret the standard correctly. This situation has gotten better over the last few years but in the early days of F2003 support I had more than one instance where a feature was not implemented correctly because the standard was mis-interpreted. I rarely turn on any optimization until I get to the actual unit testing of the software and at this stage its as much about determininig if optimization will introduce errors (still a problem that plagues almost all compilers) as it is about how much optimization will speed up the code. Only when I get to the V&V stage of a project do I look at what compiler gives the best overall performance. Even then I weight the performance gain that compiler will give against its availability to the largest possible user base. Not everyone will have access to a Cray and will gain nothing from any "superior performance" the Cray CCE compilers might give if thats the only compiler I target my code for.

Again, don't get me wrong. I applaud the Standards Committee and the developer community for still caring enough about Fortran to drag it into the 21st century
I think almost all of the features introduced in the language are useful (even some I didn't really see a use for at first like parameterized types). I just think that more involvement by people that see Fortran from the user side in the Standards process would lead to a different set of priorities on what is really important than the what we have now with a vendor/developer dominated committee who only see things from the developer/vendor side of the equation. Steve Lionel's WG5 survey is a step in the right direction. Unfortunately, I've been on enough committee's with people to know that ego's can get in the way and despite Steve and other committee members efforts there will always be a group that think the user community are a bunch of idiots and all would stink on ice and their vision of what Fortran should be is the one true religion.

RW

[Ian Harvey]

I think I get (and got) your point - I disagree with it.

I think the language feature of asynchronous input/output is useful,
even if only *one* compiler *eventually* implements it "truly", a point
that we are already well beyond.

If I would normally desire asynchronous capability, but happen to be
working on a platform that does not support that capability (for
whatever reason, which may have nothing to do with the effort put into
the Fortran compiler), what have I lost? My still compiles, my program
still gives the same observable output, what I write can be easily
ported somewhere else.

The realistic alternative to the *standard* laying out how conforming
programs should "suggest" to processors that they both desire
asynchronous input/output *and* have been written in a way that permits
asynchronous input/output (this last bit is what is really important,
from a source point of view), is to go down the path of compiler
specific directives and other non-portable gibberish. I don't want that.

I have no idea how asynchronous input/output got into the language, but
I think it is a pretty useful concept.

Knowing I can write something that will compile with several different

compilers *and give the same results*, is spectacularly more important
to me than both consistent error detection and raw performance.

A processor that could catch all possible errors and violations of the
standard would be a processor (it has to be far more than just a
compiler, as conventionally defined) that was totally unsuitable to use
in a typical production environment. I'm not sure if such a thing is
even possible. Such a processor could be quite useful in a development
environment.

I have come across a few mistakes in compilers over the years too. I
suspect one vendor in particular is heartily sick of hearing from me.

[Dick Hendrickson]

I'm still not sure. If the kind of C_ENUM is different from that of
ordinary Integer, then I think the signatures are distinguishable. The
body text starting at the end of page 285 specifically says the
arguments are distinguishable if the Kinds don't match. I forget what
the kind of C_ENUM is supposed to be. If it isn't required to be
default integer, then isn't the distinguishability processor dependent?

Dick Hendrickson

[Thomas Koenig]

Dick Hendrickson <dick.hen...@att.net> schrieb:

> I'm still not sure. If the kind of C_ENUM is different from that of
> ordinary Integer, then I think the signatures are distinguishable. The
> body text starting at the end of page 285 specifically says the
> arguments are distinguishable if the Kinds don't match. I forget what
> the kind of C_ENUM is supposed to be. If it isn't required to be
> default integer, then isn't the distinguishability processor dependent?

In the words of J3/09-007r3:

# For an enumeration, the kind is selected such that an integer type with that
# kind is interoperable (15.3.2) with the corresponding C enumeration type. The
# corresponding C enumeration type is the type that would be declared by a C
# enumeration specifier (6.7.2.2 of ISO/IEC 9899:1999) that specified C
# enumeration constants with the same values as those specified by the
# enum-def, in the same order as specified by the enum-def.

So, what does

program main
enum, bind(C)
enumerator :: red
end enum
print *,kind(red), kind(1)
end program main

print for the different compilers? For gfortran, it is
4 4

[paul.rich...@gmail.com]

Hi Dick,

Yes, the resolution is likely to be processor dependent. On my system, if I change all the INTEGER declarations in the testcase to INTEGER(8), other than the INTEGER(C_ENUM), then everything works fine with gfortran.

ans = multiIndex (1_8, 2_8, 3_8, 4_8, 5_8, 6_8)

is correctly distinguished from

ans = multiIndex (1_8, 2_8, 3_8, 4_8, 5, 6_8)

and

ans = multiIndex (1_8, 2_8, 3_8, 4_8, 5_8, 6_8, 7)

Cheers

Paul

[FortranFan]

On Sunday, October 8, 2017 at 12:17:46 PM UTC-4, Dick Hendrickson wrote:

> ..

>
> I'm still not sure. If the kind of C_ENUM is different from that of

> ordinary Integer, then I think the signatures are distinguishable. ..

@Dick Hendrickson,

Yes, that is correct - disambiguation in generic interfaces per Fortran standard is based on type, kind, and rank (TKR).

But as I mentioned earlier, it is the case with Intel Fortran and gfortran compilers that the integer kinds are all the same for the dummy arguments in the example in the original post notwithstanding one of the dummy arguments has the kind C_ENUM which is the kind of ENUMERATOR i.e., the kind that is interoperable with the corresponding C enumeration type.

Consider the following simple code:

use, intrinsic :: iso_c_binding, only : c_int
enum, bind(C)
enumerator :: foo
end enum
integer :: bar
integer :: foobar = kind(foo)
print *, "enumerator :: foo; kind(foo) = ", kind(foo)
print *, "integer :: bar; kind(bar) = ", kind(bar)
print *, "integer :: foobar = kind(foo); foobar = ", foobar
end

Upon execution with either of the above compilers, the output is

enumerator :: foo; kind(foo) = 4
integer :: bar; kind(bar) = 4
integer :: foobar = kind(foo); foobar = 4


Thus the situation indeed involves an ambiguous interface with both gfortran and Intel compilers.

[Richard Weed]

I'm still curious as to why the Intel compiler didn't die in the module with the ambiguity and also didn't gripe about an ambiguity when it I used the generic interface in a separate module later in the compilation. I changed the
code to get rid of the generic interface so this not really a big deal for me. The fact this occurs with Intel 17 maybe points to a potential flaw in how Intel is trying to resolve the ambiguity. Also, if it had just been Intel I would have not questioned the gfortran results as much but PGI 17.4 exibited the same behaviour as Intel so I was inclined to believe the professionals more than I was the amatuers.

[FortranFan]

On Sunday, October 8, 2017 at 2:44:48 PM UTC-4, Richard Weed wrote:

> ..
>

> I'm still curious as to why the Intel compiler didn't die in the module with the ambiguity and also didn't gripe about an ambiguity when it I used the generic interface in a separate module later in the compilation. I changed the
> code to get rid of the generic interface so this not really a big deal for me. The fact this occurs with Intel 17 maybe points to a potential flaw in how Intel is trying to resolve the ambiguity. Also, if it had just been Intel I would have not questioned the gfortran results as much but PGI 17.4 exibited the same behaviour as Intel so I was inclined to believe the professionals more than I was the amatuers.

@Richard Weed,

There are multiple factors at play but I think your reading of the situation is alright in some situations but highly questionable in other aspects.

Your latest comment, "I was inclined to believe the professionals more than I was the amatuers." is baseless as well as needless, especially what the two terms - professionals and amateurs - imply in the most common vernacular.

What really, really matters now, more so than any computer science skills, when it comes to Fortran compiler development is PASSION and CARING and INTEREST and ENTHUSIASM for the Fortran language, particularly given the post-1970s history in computer engineering where "FORTRAN" has essentially and effectively been looked upon with derision and worst.

In Paul Rich Thomas et al., gfortran development team consists of volunteers who bring utmost passion and caring and attention of details toward the task. Their achievements are indeed superlative compared to all their commercial peers.

From what I see, the commercial vendors struggle with the above aspects with the folks on their team, many of whom are primarily C++ developers and who perhaps view the Fortran compiler as just another C++ application.

Now when it comes to Intel Fortran compiler, I think you have a point in thinking, "this .. points to a potential flaw in how Intel is trying to resolve the ambiguity".

To give Intel its due credit, they show a healthy willingness to improve all their software products, Intel Fortran compiler being one of several dozen high-performance software products they commercialize. Accordingly, they have a new Online Support Center (OSC) you may be aware of:
https://supporttickets.intel.com/?lang=en-US

The approach instituted by Intel is for developers to report their issues directly at the OSC. I suggest you do so for all the issues you face with Intel Fortran compiler, if you are not already.

Back to the point about "a potential flaw in how Intel is trying to resolve the ambiguity", it can be proven by considering the following simple case involving an ambiguous generic interface:

--- begin simple case ---
module m

implicit none

interface

function f1( i1, i2 ) result ( r )
! Argument list
integer, intent(in) :: i1
integer, intent(in), optional :: i2
! Function result
integer :: r
end function f1

function f2( i1, i2, i3 ) result ( r )
! Argument list
integer, intent(in) :: i1
integer, intent(in) :: i2
integer, intent(in), optional :: i3
! Function result
integer :: r
end function f2

end interface

interface f
procedure f1
procedure f2
end interface

end module
--- end simpler case ---

For the above simple case, the compiler notices the ambiguous interface problem and issues an error:

--- begin compilation output for simple case ---
xx>ifort /c /standard-semantics /warn:all /check:all m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.0.124 Build 20170811
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.

m.f90(15): error #5286: Ambiguous generic interface F: previously declared speci
fic procedure F1 is not distinguishable from this declaration. [F2]
function f2( i1, i2, i3 ) result ( r )
---------------^
compilation aborted for m.f90 (code 1)
--- end compilation output for simple case ---

Now consider a slightly more complicated case that I can consider is a *minimal working example (MWE)* for what you show in the original post:

--- begin problem case ---
module m

interface

function f1( i1, i2 ) result ( r )
! Argument list
integer, intent(in), optional :: i1
integer, intent(in), optional :: i2
! Function result
integer :: r
end function f1

function f2( i1, i2, i3, i4 ) result ( r )
! Argument list
integer, intent(in) :: i1
integer, intent(in) :: i2
integer, intent(in), optional :: i3
integer, intent(in), optional :: i4
! Function result
integer :: r
end function f2

end interface

interface f
procedure f1
procedure f2
end interface

end module
--- end problem case ---

Upon compilation, no errors or warnings are generated:
--- begin compilation output for problem case ---
xx>ifort /c /standard-semantics /warn:all /check:all m.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.0.124 Build 20170811
Copyright (C) 1985-2017 Intel Corporation. All rights reserved.
--- end compilation output for problem case ---

My read now is Intel Fortran compiler does indeed intend to generate compilation-time diagnostics for ambiguous generic interfaces in accordance with C1215 constraint (Fortran 2008, the 'official' version yet of the standard). It succeeds with the simple case shown above but not with the slightly more complex situation.

So I have submitted a request with Intel Fortran team at the OSC to enhance their compiler further; will see how they respond.

[Richard Weed]

Thanks again to all who commented on this subject. One thought occured to me though that these types of problems could have been avoided if at the time optional arguments were added to the standard an additional constraint on their use beyond the TKR constraints was required. Specifically, optional arguments
could only be passed as keyword arguments in the calling routine. This is in
line with the "rules" suggested by Clerman and Spector to reduce the possible ambiguity that can arise with just the TKR rules. This would allow gfortran just issue a warning instead of an error in my example and delay final resolution of the optional arguments to when the generic interface is actually used. This appears to be what is happening with Intel even though its now clear that is a possible implementation bug in the compiler. If the optional arguments had the further restriction of being passed only as keywords, my initial coding would be valid. Unfortunately we are too far along the current path with TKR related issues like this to go back and fix it.

RW

[David Thompson]

On Sun, 8 Oct 2017 18:09:38 +0000 (UTC), Thomas Koenig
<tko...@netcologne.de> wrote:

> Dick Hendrickson <dick.hen...@att.net> schrieb:
>
> > I'm still not sure. If the kind of C_ENUM is different from that of
> > ordinary Integer, then I think the signatures are distinguishable. The
> > body text starting at the end of page 285 specifically says the
> > arguments are distinguishable if the Kinds don't match. I forget what
> > the kind of C_ENUM is supposed to be. If it isn't required to be
> > default integer, then isn't the distinguishability processor dependent?
>
> In the words of J3/09-007r3:
>
> # For an enumeration, the kind is selected such that an integer type with that
> # kind is interoperable (15.3.2) with the corresponding C enumeration type. The
> # corresponding C enumeration type is the type that would be declared by a C
> # enumeration specifier (6.7.2.2 of ISO/IEC 9899:1999) that specified C
> # enumeration constants with the same values as those specified by the
> # enum-def, in the same order as specified by the enum-def.
>

The C standard (did and) does allow enum types to differ; each must
be compatible with some supported integer type that has sufficient
range to cover the specified (declared) values. But ...

> So, what does
>
> program main
> enum, bind(C)
> enumerator :: red
> end enum
> print *,kind(red), kind(1)
> end program main
>
> print for the different compilers? For gfortran, it is
> 4 4

... gcc, which is the companion for gfortran, by default does not use
the permission granted by the standard, and makes all enum types 'int'
which always has sufficient range (enum _values_ cannot exceed int)
and which corresponds to Ftn default INTEGER.