Ambiguous interfaces in gfortran -- who's right?
Rich Townsend
I've just been trying out gfortran with my code library. When compiling my
root-finding module, I get the following error:
<<<
gfortran -I/usr/lib -I/usr/local/include/fortran/gfortran -O2 -std=f2003 -c
b3_root.f90
b3_root.f90:235.45:
module procedure b3rt_find_root_muller_Z
1
Error: Ambiguous interfaces 'b3rt_find_root_muller_z' and
'b3rt_find_root_secant_z' in generic interface 'b3rt_find_root' at (1)
make: *** [b3_root.mod] Error 1
<<<
The interfaces in question are as follows:
<<<
function b3rt_find_root_muller_Z (z_1, z_2, z_3, f_func, z_tol_r, z_tol_i, &
& max_iterations, f_1, f_2, f_3,
relative_tol) result (z)
complex(KIND(0.D0)), intent(in) :: z_1
complex(KIND(0.D0)), intent(in) :: z_2
complex(KIND(0.D0)), intent(in) :: z_3
interface
function f_func (z) result (f)
implicit none
complex(KIND(0.D0)), intent(in) :: z
complex(KIND(0.D0)) :: f
end function f_func
end interface
real(KIND(0.D0)), intent(in) :: z_tol_r
real(KIND(0.D0)), intent(in) :: z_tol_i
integer, intent(in), optional :: max_iterations
complex(KIND(0.D0)), intent(in), optional :: f_1
complex(KIND(0.D0)), intent(in), optional :: f_2
complex(KIND(0.D0)), intent(in), optional :: f_3
logical, intent(in), optional :: relative_tol
complex(KIND(0.D0)) :: z
<<<
and
<<<
function b3rt_find_root_secant_Z (z_1, z_2, f_func, z_tol_r, z_tol_i, &
& max_iterations, f_1, f_2,
relative_tol) result (z)
complex(KIND(0.D0)), intent(in) :: z_1
complex(KIND(0.D0)), intent(in) :: z_2
interface
function f_func (z) result (f)
implicit none
complex(KIND(0.D0)), intent(in) :: z
complex(KIND(0.D0)) :: f
end function f_func
end interface
real(KIND(0.D0)), intent(in) :: z_tol_r
real(KIND(0.D0)), intent(in) :: z_tol_i
integer, intent(in), optional :: max_iterations
complex(KIND(0.D0)), intent(in), optional :: f_1
complex(KIND(0.D0)), intent(in), optional :: f_2
logical, intent(in), optional :: relative_tol
complex(KIND(0.D0)) :: z
<<<
Now, based on my understanding of TKR matching, these aren't ambiguous at all.
Am I right -- or have I just learned something?
cheers,
Rich
glen herrmannsfeldt
> I've just been trying out gfortran with my code library. When compiling
> my root-finding module, I get the following error:
(snip)
> Error: Ambiguous interfaces 'b3rt_find_root_muller_z' and
> 'b3rt_find_root_secant_z' in generic interface 'b3rt_find_root' at (1)
(snip)
> function b3rt_find_root_muller_Z (z_1, z_2, z_3, f_func, z_tol_r,
> z_tol_i, &
> & max_iterations, f_1, f_2, f_3,
> relative_tol) result (z)
> complex(KIND(0.D0)), intent(in) :: z_1
> complex(KIND(0.D0)), intent(in) :: z_2
> complex(KIND(0.D0)), intent(in) :: z_3
> interface
> function f_func (z) result (f)
> implicit none
> complex(KIND(0.D0)), intent(in) :: z
> complex(KIND(0.D0)) :: f
> end function f_func
> end interface
> real(KIND(0.D0)), intent(in) :: z_tol_r
> real(KIND(0.D0)), intent(in) :: z_tol_i
> integer, intent(in), optional :: max_iterations
> complex(KIND(0.D0)), intent(in), optional :: f_1
> complex(KIND(0.D0)), intent(in), optional :: f_2
> complex(KIND(0.D0)), intent(in), optional :: f_3
> logical, intent(in), optional :: relative_tol
> complex(KIND(0.D0)) :: z
> function b3rt_find_root_secant_Z (z_1, z_2, f_func, z_tol_r, z_tol_i, &
> & max_iterations, f_1, f_2,
> relative_tol) result (z)
>
> complex(KIND(0.D0)), intent(in) :: z_1
> complex(KIND(0.D0)), intent(in) :: z_2
> interface
> function f_func (z) result (f)
> implicit none
> complex(KIND(0.D0)), intent(in) :: z
> complex(KIND(0.D0)) :: f
> end function f_func
> end interface
> real(KIND(0.D0)), intent(in) :: z_tol_r
> real(KIND(0.D0)), intent(in) :: z_tol_i
> integer, intent(in), optional :: max_iterations
> complex(KIND(0.D0)), intent(in), optional :: f_1
> complex(KIND(0.D0)), intent(in), optional :: f_2
> logical, intent(in), optional :: relative_tol
> complex(KIND(0.D0)) :: z
> Now, based on my understanding of TKR matching, these aren't ambiguous
> at all. Am I right -- or have I just learned something?
I presume it has to be unambiguous without the optional arguments.
It would seem, then, that it is only ambiguous if you don't
consider REAL and COMPLEX as different types.
They have the same KIND and RANK.
That doesn't seem right
It might be convenient to allow an array of two REAL to
be passed in place of COMPLEX (or an array of 2*N REAL
in place if N COMPLEX). (Not that I believe the standard
allows for it, though, but I believe it was once common.)
-- glen
Michael Metcalf
"Rich Townsend" <rh...@barVOIDtol.udel.edu> wrote in message
news:fgf7la$e6o$1...@scrotar.nss.udel.edu...
>
> Now, based on my understanding of TKR matching, these aren't ambiguous at
> all. Am I right -- or have I just learned something?
I think you're right (and so does Intel), and so you've learned there's a
bug in the compiler.
Regards,
Mike Metcalf
Rich Townsend
Thanks for checking, Mike; I think I'll file a bug report.
For any gfortran folk listening (Steve Kargl?), this is version 4.2.2 running on
x86_64 Gentoo Linux.
cheers,
Rich
Craig Powers
It may be something that's fixed in 4.3... I know I've seen stuff about
ambiguousness of interfaces on the list, but I don't recall offhand if
it fits the problem you've seen.
Tobias Burnus
> gfortran -I/usr/lib -I/usr/local/include/fortran/gfortran -O2 -std=f2003 -c
> 1
> Error: Ambiguous interfaces 'b3rt_find_root_muller_z' and
> 'b3rt_find_root_secant_z' in generic interface 'b3rt_find_root' at (1)
> Now, based on my understanding of TKR matching, these aren't ambiguous at all.
> Am I right -- or have I just learned something?
I believe that NAG f95 and gfortran rightly reject this example; I
failed to come up with an example why they are really
indistinguishable and thus I will argue with the standard ;-)
Unless, I overlooked something interfaces are:
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]
Looking at the Fortran 2003 standard ("16.2.3 Restrictions on generic
declarations"), the items "(1)" and "(2)" do not apply. Let's check
for "(3)".
"(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"
Ok, the 4th argument is different: real/complex type.
"(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."
Ok, there is (only) z_3 at the 3rd position.
However, this is followed by the following constrain:
"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."
I don't see this being fulfilled.
Therefore, I believe the program is invalid as diagnosed by gfortran
and NAG f95, even though openf95, ifort, g95, Lahey and sunf95 don't
reject it.
But feel free to convince me that it is valid - it would not be the
first time I have misread the standard or missed a part of the
standard.
Tobias
PS: Thanks to Mike Metcalf for answering the PROCEDURE question the
other day; I must have been blind not realizing that the paragraph
indeed contained what I was looking for.
PPS: The gfortran bug is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33997.
Michael Metcalf
"Tobias Burnus" <bur...@net-b.de> wrote in message
news:1194285308....@k79g2000hse.googlegroups.com...
>
> "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."
>
> I don't see this being fulfilled.
>
> Therefore, I believe the program is invalid as diagnosed by gfortran
> and NAG f95, even though openf95, ifort, g95, Lahey and sunf95 don't
> reject it.
>
> But feel free to convince me that it is valid
>
I have spent half an hour trying to prove you wrong, only to come to the
conclusion that you are right. Sorry for misleading folks.
Regards,
Mike Metcalf
Steve Lionel
> Therefore, I believe the program is invalid as diagnosed by gfortran
> and NAG f95, even though openf95, ifort, g95, Lahey and sunf95 don't
> reject it.
I also agree with your analysis. ifort bug id 81135.
Steve
Jugoslav Dujic
| On Nov 2, 2:11 pm, Rich Townsend <r...@barVOIDtol.udel.edu> wrote:
|| gfortran -I/usr/lib -I/usr/local/include/fortran/gfortran -O2 -std=f2003 -c
|| module procedure b3rt_find_root_muller_Z
|| 1
|| Error: Ambiguous interfaces 'b3rt_find_root_muller_z' and
|| 'b3rt_find_root_secant_z' in generic interface 'b3rt_find_root' at (1)
|
|| Now, based on my understanding of TKR matching, these aren't ambiguous at
|| all. Am I right -- or have I just learned something?
|
| I believe that NAG f95 and gfortran rightly reject this example; I
| failed to come up with an example why they are really
| indistinguishable and thus I will argue with the standard ;-)
|
| (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"
Would anyone be so kind to demonstrate the ambiguity to a poor layman?
I'm having hard time wading through the standard's dense language...
<supposition>
As I got it thus far, there isn't an actual ambiguity, i.e. one can not
construct an ambiguous calling sequence -- rather, the interfaces do not
satisfy the standard's constraint (3), which was [supposedly] conceived
to guard against an entirely different set of circumstances. Rich's
original sample was thus only an unfortunate intersection.
</supposition>
Right? Wrong?
--
Jugoslav
___________
www.xeffort.com
Please reply to the newsgroup.
You can find my real e-mail on my home page above.
James Van Buskirk
news:5palf5F...@mid.individual.net...
> <supposition>
> As I got it thus far, there isn't an actual ambiguity, i.e. one can not
> construct an ambiguous calling sequence -- rather, the interfaces do not
> satisfy the standard's constraint (3), which was [supposedly] conceived
> to guard against an entirely different set of circumstances. Rich's
> original sample was thus only an unfortunate intersection.
> </supposition>
I can't do anything to disprove your supposition. Generic procedures
are not as cool as they could be in Fortran. Fortran does have the
complication that procedure arguments are in the worst case wild
cards. A procedure in a module could have an implicitly typed dummy
that is never used. Is this dummy a variable of the implicit type, a
function of that type, or a subroutine? It's legal, I think, to make
a procedure with an ambiguous dummy like this a specific procedure of
a generic procedure.
Here's a little example of what I'm talking about:
module ambiguous
implicit none
interface both
module procedure test1, test2
end interface both
contains
function test1(x)
implicit integer(x)
integer test1
test1 = 1
end function test1
function test2(x)
interface
subroutine x()
end subroutine x
end interface
integer test2
test2 = 2
end function test2
subroutine test3
end subroutine test3
end module ambiguous
program main
use ambiguous
implicit none
write(*,*) both(1)
write(*,*) both(test3)
end program main
Now, is there some language rule that tells us that the dummy
argument of function test1 is an integer and not a subroutine?
I suppose there is because gfortran can figure it out:
C:\Program Files\Microsoft Visual Studio
8\James\clf>c:\gfortran\win64\bin\x86_6
4-pc-mingw32-gfortran ambiguous.f90 -oambiguous
C:\Program Files\Microsoft Visual Studio 8\James\clf>ambiguous
1
2
ifort can't seem to handle this example:
C:\Program Files\Microsoft Visual Studio 8\James\clf>ifort ambiguous.f90
Intel(R) Fortran Compiler for Intel(R) EM64T-based applications, Version 9.1
Build 20061104
Copyright (C) 1985-2006 Intel Corporation. All rights reserved.
ambiguous.f90(7) : Error: This name does not have a type, and must have an
expli
cit type. [X]
function test1(x)
---------------------^
I think that may be a bug in ifort, but I'm not sure...
> --
> Jugoslav
> ___________
> www.xeffort.com
I looked at your xeffort stuff and there were a lot of desirable things
in there but installation with Xeffort_IVF_1221.exe said I didn't have
IVF 9.0 whereas I had IVF 9.1. Also some files such as xftapity.f90
have issues. Do you have a program that generates these out of C header
files (that could possibly be fixed) or is everything done by hand?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Jugoslav Dujic
| I looked at your xeffort stuff and there were a lot of desirable things
| in there but installation with Xeffort_IVF_1221.exe said I didn't have
| IVF 9.0 whereas I had IVF 9.1.
1.2.22 is the last version. The installer is written in InnoSetup, and
its maintenance has been an uphill struggle against Intel and Microsoft
ever-changing registry conventions and abundance of VF/VS versions.
Bug reports are always welcome; the setup should leave a file named
XeffortSetupIVF.log along the installer's exe, for [sort of] debugging
purposes. Checking my CVS history of the installation script, I see
something was changed between 1.2.21 and 1.2.22, but I'm not sure if
it affects the behavior you describe.
Having taken a look at the code, the relevant line is outdated and
somewhat misleading:
nIntegrations := GetIntegrations();
if (nIntegrations=0) then begin
Result := MsgBox('Setup has detected that you do not have IVF 8.1 or 9.0
installed...
actually, it will complain if the Intel Visual Studio *integration*
is not installed -- is it ? -- and the version numbers are bad (it supports
all the way from 8.1 to 10.0).
| Also some files such as xftapity.f90
| have issues. Do you have a program that generates these out of C header
| files (that could possibly be fixed) or is everything done by hand?
It's done by hand; [often blatantly violating copyright by copying from
DFWIN*.f90 files :-D ]. What issues?
glen herrmannsfeldt
(snip)
> I can't do anything to disprove your supposition. Generic procedures
> are not as cool as they could be in Fortran. Fortran does have the
> complication that procedure arguments are in the worst case wild
> cards. A procedure in a module could have an implicitly typed dummy
> that is never used. Is this dummy a variable of the implicit type, a
> function of that type, or a subroutine? It's legal, I think, to make
> a procedure with an ambiguous dummy like this a specific procedure of
> a generic procedure.
It would seem to work as long as they are all the same size.
How about the case where the only reference to the dummy is an
actual argument to another subroutine or function?
In that case, it could still work if in all cases an address is
passed, and that address is passed along to the called routine.
-- glen
Tobias Burnus
> Here's a little example of what I'm talking about:
>
> implicit integer(x)
> integer test1
>
> interface
> subroutine x()
> end subroutine x
> end interface
> integer test2
I believe this program is invalid:
"Two dummy arguments are distinguishable if neither is a subroutine
and neither
is TKR compatible (5.1.1.2) with the other."
Your test case is rejected by ifort and NAG f95, but accepted by
gfortran, g95, openf95 and sunf95.
Tobias
PS: Filled as gfortran bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34004
Steve Lionel
> Now, is there some language rule that tells us that the dummy
> argument of function test1 is an integer and not a subroutine?
> I suppose there is because gfortran can figure it out:
Hmm - I know that we fixed a similar bug a while ago, but this test
case is still a problem for ifort (ignoring the other issue you found
relating to IMPLICIT). I'll report both issues.
Steve
Jugoslav Dujic
| On Nov 6, 10:25 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
|| Here's a little example of what I'm talking about:
||
|| function test1(x)
|| implicit integer(x)
|| integer test1
||
|| function test2(x)
|| interface
|| subroutine x()
|| end subroutine x
|| end interface
|| integer test2
|
| and neither
| is TKR compatible (5.1.1.2) with the other."
Your point is taken, but the Standard's point of -- let me quote you:
"A bit oddly the Fortran standard does not distinguish between variables and
functions and subroutines are wild matches."
...is not taken. It's reasonable that dummy arguments which are FUNCTIONs and
SUBROUTINEs are not mutually distinguishable for the purpose at hand, nor that
their own signature is a disambiguator. However, it's *not* reasonable that
FUNCTIONs/SUBROUTINEs are not distinguishable from something else.
...unless it were possible that a dummy argument which is a procedure can be
declared without an EXTERNAL or INTERFACE statement -- can it? Me say no, but
I've been wrong many times before.
Walter Spector
> ...
> ...unless it were possible that a dummy argument which is a procedure can be
> declared without an EXTERNAL or INTERFACE statement -- can it? Me say no, but
> I've been wrong many times before.
Consider:
module mysubs
! implicit none intentionally omitted
contains
subroutine sub (x)
call x ()
end subroutine
end module
Or similarly:
module myfns
! implicit none intentionally omitted
contains
subroutine prt (f)
print *, f ()
end subroutine
end module
In both the above cases, the compiler should be able to deduce the
external attribute by how it is used.
W.
Rich Townsend
Thanks for the analysis. I always get confused by the fact that TKR matching
ignores whether one of the arguments is a function.
Out of interest, what does TKR matching do with subroutines? Do they get ignored
in the argument list?
Many thanks to all who responded,
cheers,
Rich
Steve Lionel
> Out of interest, what does TKR matching do with subroutines? Do they get ignored
> in the argument list?
For the purpose of disambiguation, yes, they are ignored. If there is
nothing else to disambiguate, then the interfaces are ambiguous.
Steve
Jugoslav Dujic
Ah that's legal? I sort of suspected that, but didn't feel like
researching it -- I never program like that, and would subject any
of my coworkers to Chinese water torture, should I discover something
similar in their code.
Rich Townsend
So are these ambiguous?:
subroutine foo(a, b)
subroutine bar(b, a)
...when in both cases a is a subroutine, and b a real?
Rich
Craig Dedo
>
> Thanks for the analysis. I always get confused by the fact that TKR matching
> ignores whether one of the arguments is a function.
>
> Out of interest, what does TKR matching do with subroutines? Do they get
> ignored in the argument list?
>
> Many thanks to all who responded,
The issue of whether procedure-ness, i.e., whether a name is for a function
or subroutine, should be used in generic resolution has come up many times at J3
meetings. When I was on J3 (1994-2003), the answer was always, "No,
procedure-ness is not used in generic resolution". Further, the majority
believed that was the way it should remain.
I always thought that this rule was counter-intuitive. However, I never was
able to persuade a majority to my point of view. It also seems to me that it
would not be very difficult or costly to change the rule. Compilers already
know whether or not a given name is the name of a procedure. That information
has to be in the symbol table in order to generate correct object code. If I am
wrong about this, perhaps one or more of the readers who work on compilers could
point out the difficulties of changing the rule to use procedure-ness in generic
resolution.
IIRC, procedure-ness is not used in generic resolution in Fortran 2003. I
am unsure if that will change in Fortran 2008. Perhaps one of the current
members of J3 can clarify this for us.
--
Craig Dedo
17130 W. Burleigh Place
P. O. Box 423
Brookfield, WI 53008-0423
Voice: (262) 783-5869
Fax: (262) 783-5928
Mobile: (414) 412-5869
E-mail: <cd...@wi.rr.com> or <cr...@ctdedo.com>
Richard Maine
> The issue of whether procedure-ness, i.e., whether a name is for a
> function or subroutine, should be used in generic resolution has come up
> many times at J3 meetings.
...
> It also seems to me that it
> would not be very difficult or costly to change the rule.
The generic rules are already incredibly complicated. I don't know
anyone who can mentally grasp the whole mix. One tends to have to drag
out the standard and go through that part line by line in order to check
the non-trivial cases. You can't just reason it out logically. Anyway, I
can't. Other quite bright people (including several contributors to this
thread) also show evidence of not being able to get it right off the top
of their head in all cases.
This is also an area where there are many proposals for enhancement.
Just about every one of them adds extra bits to the already complicated
mix. Some of the proposed enhancements conflict with each other.
I suspect that any change at all in this area is difficult and costly.
That doesn't mean that no changes should ever be made. I believe that
the f2008 daft might have one; certainly some have been proposed on
occasion. But any change requires a lot of careful study. I have a
pretty much knee-jerk reaction to any proposal in this area that is
described as not being difficult. To me that usually implies more that
the proposer hasn't realized all the complications instead of that they
don't exist. No, I'm not goinbg to try to explain all the complications.
I don't remember them in detail, as they are.... complicated.
I'm not entirely happy with some aspects of generic resolution either.
But I know that it is messy to change.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Steve Lionel
> So are these ambiguous?:
>
> subroutine foo(a, b)
> subroutine bar(b, a)
>
> ...when in both cases a is a subroutine, and b a real?
Well, yes, but that would be true no matter what "a" was (assuming it
was the same in both cases.) Lots of people forget about keywords in
calls. Which of foo or bar is called by:
call generic(a=thing1,b=thing2)
?
The bit about subroutines is that a dummy argument that is a
subroutine does not participate in generic disambiguation, so there
has to be something else to tell them apart.
Steve
James Van Buskirk
> James Van Buskirk wrote:
> | I looked at your xeffort stuff and there were a lot of desirable things
> | in there but installation with Xeffort_IVF_1221.exe said I didn't have
> | IVF 9.0 whereas I had IVF 9.1.
> 1.2.22 is the last version. The installer is written in InnoSetup, and
> its maintenance has been an uphill struggle against Intel and Microsoft
> ever-changing registry conventions and abundance of VF/VS versions.
I thought I was getting the latest version last night. Perhaps I was
tired, or perhaps it's just not obvious from your website.
> Bug reports are always welcome; the setup should leave a file named
> XeffortSetupIVF.log along the installer's exe, for [sort of] debugging
> purposes. Checking my CVS history of the installation script, I see
> something was changed between 1.2.21 and 1.2.22, but I'm not sure if
> it affects the behavior you describe.
Starting setup...
Can't find any VF integration installations
No Intel Fortran installed!
> actually, it will complain if the Intel Visual Studio *integration*
> is not installed -- is it ? -- and the version numbers are bad (it
> supports
> all the way from 8.1 to 10.0).
Looking under start->control panel->add or remove programs, it says I
have Intel(R) Visual Fortran Compiler 9.1 Integrations in Microsoft
Visual Studio* installed
> | Also some files such as xftapity.f90
> | have issues. Do you have a program that generates these out of C header
> | files (that could possibly be fixed) or is everything done by hand?
> It's done by hand; [often blatantly violating copyright by copying from
> DFWIN*.f90 files :-D ]. What issues?
Well, pointers and handles should be typed as INTEGER(INT_PTR_KIND) in
CVF and early versions of ifort. In the latest versions of ifort and
gfortran, enough f03 is available that the transportable INTEGER(C_INTPTR_T)
is the right thing to do. A concise reference:
http://www.jorgon.freeserve.co.uk/GoasmHelp/64bits.htm#datat
Also functions that return a BOOL should be typed as returning a
default INTEGER, because BOOL is an alias for int in the Windows
headers somewhere. A while back I posted an example where I showed
that some compilers, including the version of ifort I an using now,
could violate truth tables if given LOGICAL values that weren't
set via literals or intrinsic operators. I was going to post the
whole thing again, but it occurred to me that it is better to
simply reference the message:
http://groups.google.com/group/comp.lang.fortran/msg/87afb6ac1ff0509e
Now, I was criticized for expecting that truth tables should still
be valid for LOGICAL values that were set other than through literals
or intrinsic operators but in the meantime, perhaps Intel has fixed this:
http://softwarecommunity.intel.com/isn/Community/en-US/forums/post/30239918.aspx
But the issue is that setting LOGICAL variables to arbitrary values can
create situations where truth tables don't work any more, at least on
some compilers including an old version of ifort. Since C programs
routinely set variables to arbitrary values and then use the results
in logical contexts such as if statements, it's quite dangerous for
Fortran programs to accept anything C returns as a LOGICAL value. A
classic example in C++ is if(ins && ins.good()) ... where ins is an
instance of a complicated class. A more portable way to handle these
return values is
if(transfer(MessageBox(hWnd,lpText,lpCaption,uType),1) /= 0) then...
portable in the sense that even if the interfaces you're using specify
LOGICAL return values, they can be treated properly as INTEGERs. Oh
well, enough ranting about Windows interfacing issues. Have you seen
my example http://home.comcast.net/~kmbtib/Fortran_stuff/HelloWin.f90
that works in gfortran? I think it should work in ifort, too, but
there may be a bug preventing it from working in *32 mode, at least
that's my take on another thread from Intel's website. It would
be nice to have a more portable BINC(C) version of xeffort, but I
think that even then gfortran would need significant upgrading to
do Windows: I think it can't do STDCALL so for now only x64 works,
and it seems there is no way to create a /subsystem:windows program,
only /subsystem:console. Maybe g95 can do better but I haven't looked
at it since I went x64.
Chip Coldwell
> I believe that the f2008 daft
Typo or Freudian slip? You decide ....
Chip
--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
Somerville, Massachusetts, New England
James Van Buskirk
news:13j13gk...@corp.supernews.com...
> module mysubs
> ! implicit none intentionally omitted
> contains
> subroutine sub (x)
> call x ()
> end subroutine
> end module
> Or similarly:
> module myfns
> ! implicit none intentionally omitted
> contains
> subroutine prt (f)
> print *, f ()
> end subroutine
> end module
> In both the above cases, the compiler should be able to deduce the
> external attribute by how it is used.
Also if the dummy argument is used as an actual argument the procedure
needs an EXTERNAL statement. I was thinking about this last night
and started feeling bad about my example because there may be some
rule in the standard that says that if a dummy argument is not explicitly
given a type and not used in an EXTERNAL statement, not CALLed as a
subroutine nor referenced as a function, that it is not a procedure.
This seems to be the de facto behavior for a couple of compilers. If
all compilers have this behavior but the standard doesn't, perhaps it
would make more sense to fix the standard than change all the compilers.
glen herrmannsfeldt
(snip)
> ...is not taken. It's reasonable that dummy arguments which are FUNCTIONs and
> SUBROUTINEs are not mutually distinguishable for the purpose at hand, nor that
> their own signature is a disambiguator. However, it's *not* reasonable that
> FUNCTIONs/SUBROUTINEs are not distinguishable from something else.
I now see how complicated this can get. An actual argument that is a
subroutine or function name is declared EXTERNAL, but no indication
to separate subroutine names from function names. In Fortran 66,
section 10.1, there are eight classes of names.
Class VII: "An external procedure which cannot be classified as either
a subroutine or external function in the program unit in question."
In 10.1.4: "The only case where a symbolic name is in Class VII occurs
when the name appears only in an EXTERNAL statement and as an actual
argument to an external procedure in a program unit." I believe this
usage has not been removed in more recent standards.
> ...unless it were possible that a dummy argument which is a procedure can be
> declared without an EXTERNAL or INTERFACE statement -- can it? Me say no, but
> I've been wrong many times before.
In Fortran 66 class V, external function it it:
"(1) Appears immediately following the word FUNCTION in a
FUNCTION statement.
(2) Is not in Class I, Class II, Class IV, or Class VI and
appears immediately followed by a left parenthesis on
every occurrence except in a type-statement, in an EXTERNAL
statement, or as an actual argument. There must be at least
one such reference in the program unit in which it is
so used."
Class I, II, IV, and VI are, respectively, array or array element,
variable, intrinsic function, and subroutine. Note the "in an
EXTERNAL statement or as an actual argument." Again, I believe this
has not been removed in later versions of the standard.
I am still not sure about:
EXTERNAL XYZ
CALL SUB1(XYZ)
STOP
END
SUBROUTINE SUB1(ABC)
CALL SUB2(ABC)
RETURN
END
SUBROUTINE SUB2(DEF)
CALL DEF
RETURN
END
SUBROUTINE XYZ
PRINT *,'XYZ'
RETURN
END
g95 gives a warning:
Warning (155): Inconsistent types (REAL(4)/PROCEDURE)
in actual argument lists at (1) and (2)
but otherwise it works fine. That warning would probably not occur if
they were compiled separately.
-- glen
glen herrmannsfeldt
(snip)
> Also if the dummy argument is used as an actual argument the procedure
> needs an EXTERNAL statement. I was thinking about this last night
> and started feeling bad about my example because there may be some
> rule in the standard that says that if a dummy argument is not explicitly
> given a type and not used in an EXTERNAL statement, not CALLed as a
> subroutine nor referenced as a function, that it is not a procedure.
> This seems to be the de facto behavior for a couple of compilers. If
> all compilers have this behavior but the standard doesn't, perhaps it
> would make more sense to fix the standard than change all the compilers.
Maybe that is it. I have gotten used to the fact that dummy arguments
don't need to be in EXTERNAL statements, especially as the name isn't
an external name. Until procedure pointers in F2003, dummy arguments
corresponding to actual argument procedure names are sort of the lost
sheep of the standard. They are more defined as what they are not,
than what they are. I have always read the EXTERNAL statement as
defining a name that is external.
I don't see that the standard disallows the requirement that a
dummy procedure reference be in an EXTERNAL statement.
-- glen
Richard Maine
> In Fortran 66,
> section 10.1, there are eight classes of names.
>
> Class VII: "An external procedure which cannot be classified as either
> a subroutine or external function in the program unit in question."
...
> I believe this
> usage has not been removed in more recent standards.
Right. In fact, I think the usage has been extended in that you can have
procedure pointers with the same indeterminancy. I'm not actually 100%
sure of that part, but I think I recall it being the case, mostly
because I recall aguing against such extension, but losing.
I personally find this to be a strange class of beast. It can give rise
to all kinds of "interesting" interpretation questions.
Walter Spector
> ...
> Also if the dummy argument is used as an actual argument the procedure
Yes. It is kinda weird that the following is illegal:
module badsubs
! implicit none intentionally omitted
contains
subroutine sub (x)
call x () ! Legal since pre-F66
call sub2 (x) ! Illegal because no EXTERNAL statement
end subroutine
end module
Same with a function version.
A reasonable person might surmise that since in the first CALL we discover
that X is a procedure, and even a subroutine, that we could then use this
knowledge in the second call - and an EXTERNAL statement would not be
needed. However strictly Standard-speaking, the 2nd usage is still illegal.
Some compilers detect this, some don't.
W.
wclo...@lanl.gov
> On Nov 6, 11:47 am, Rich Townsend <r...@barVOIDtol.udel.edu> wrote:
>
> > So are these ambiguous?:
>
> > subroutine foo(a, b)
> > subroutine bar(b, a)
>
> > ...when in both cases a is a subroutine, and b a real?
>
> Well, yes, but that would be true no matter what "a" was (assuming it
> was the same in both cases.) Lots of people forget about keywords in
> calls. Which of foo or bar is called by:
>
> call generic(a=thing1,b=thing2)
How does this differ in any significant aspect from the problem of
disambiguating for the case where a is an integer and b is a real?
>
> ?
>
> The bit about subroutines is that a dummy argument that is a
> subroutine does not participate in generic disambiguation, so there
> has to be something else to tell them apart.
>
> Steve
Note that a subroutine does not participate in disambiguation because
the standard says it doesn't, not because it is not possible to
disambiguate. There are functional languages where the equivalent is
routinely done to disambiguate overloaded functions. That
disambiguation does require a more careful description of the type
systems of procedures than the Fortran language currently provides. In
particular the procedures need to be differentiated not only in terms
of the types (including size, shape, purity, etc) of the values they
return (or don't return in the case of subroutines) but also in terms
of the types of their arguments. Yes optional/keyword arguments (and
procedure pointers) provide a potential source of ambiguity. However
that source of ambiguity is recognizable statically, provided the
interfaces are explicit, and an appropriate error message can be
issued. Whether it is worthwhile to
1. Provide a more detailed type system for procedures
2. Disambiguate on dummy procedure type if the dummies interface is
explicit.
A. Provide meaningful error messages if the interface is not explicit.
Unfortunately users don't always understand what is meant by an
explicit interface.
B. Provide meaningful error messages when overloaded procedures in the
same scope cannot be disambiguated because their procedure "types" do
not differ. Unfortunately users have trouble understanding detailed
scoping rules, and would probably have troubles understanding the
details of procedure types.
3. Recognize when the "type" of the actual procedure argument is
ambiguous, i.e., if the actual does not have an explicit interface,
and report an error message if standard conformance is required. (Note
in particular that it may be possible that only one of the procedures
to be disambiguated takes a procedure argument at a given position,
and an external procedure without an explicit interface is supplied at
that position. This appears to be how other want to disambiguate, but
I do consider it error prone.)
4. Recognize when it is not possible to disambiguate between
procedures because of the keyword problem noted above, and report the
appropriate error under standard conformance.
is a different matter. Particularly if you then deal with users'
subsequent desire to have polymorphic types (i.e. procedure dummy
arguments whose argument types or result types have to match those of
other dummy arguments of loosely specified types), and the more
complicated type systems (and resulting error messages) entailed with
those types.
glen herrmannsfeldt
(snip)
> module badsubs
> ! implicit none intentionally omitted
> contains
> subroutine sub (x)
> call x () ! Legal since pre-F66
> call sub2 (x) ! Illegal because no EXTERNAL statement
> end subroutine
> end module
> A reasonable person might surmise that since in the first CALL we discover
> that X is a procedure, and even a subroutine, that we could then use this
> knowledge in the second call - and an EXTERNAL statement would not be
> needed. However strictly Standard-speaking, the 2nd usage is still
> illegal.
Is it more obvious that this one is illegal?
module badsubs
! implicit none intentionally omitted
contains
subroutine sub (x)
call sub2 (x) ! Illegal because no EXTERNAL statement
call x () ! Legal since pre-F66
end subroutine
end module
It isn't so obvious what order the compiler needs to know things.
-- glen
John Harper
Walter Spector <w6ws_xt...@earthlink.net> wrote:
>
> subroutine sub (x)
> call x () ! Legal since pre-F66
> call sub2 (x) ! Illegal because no EXTERNAL statement
> end subroutine
>
>that X is a procedure, and even a subroutine, that we could then use this
>knowledge in the second call - and an EXTERNAL statement would not be
>needed. However strictly Standard-speaking, the 2nd usage is still
>illegal. Some compilers detect this, some don't.
Even the first usage, call x (), is IMHO illegal if subroutine x is
internal in a main program that uses module badsubs, because internal
procedures can't be actual arguments.
The obvious other two places to declare x are inside module badsubs
(IMHO legal) or separate from both the module and the main program.
In the latter case, g95 and NAG f95 insist on EXTERNAL x somewhere.
EXTERNAL x may (according to those compilers) appear either in the
module before "contains" or in the main program after "USE badsubs".
But both g95 and NAG f95 reject the version below, presumably because
the EXTERNAL x inside the module subroutine sub is invisible to the
main program, just as a declaration of a variable local to the
subroutine would be. Lower case keywords below are Walter's, upper mine.
module badsubs
! implicit none intentionally omitted
contains
subroutine sub (x)
EXTERNAL x ! Illegal with the main program below?
call x () ! Legal since pre-F66
end subroutine
end module
PROGRAM badext2
USE badsubs
CALL sub(x)
END PROGRAM badext2
SUBROUTINE x()
PRINT *,'Inside subroutine x'
END SUBROUTINE x
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045
Walter Spector
> module badsubs
> ! implicit none intentionally omitted
> contains
> subroutine sub (x)
> EXTERNAL x ! Illegal with the main program below?
> call x () ! Legal since pre-F66
> end subroutine
> end module
>
> PROGRAM badext2
> USE badsubs
> CALL sub(x)
> END PROGRAM badext2
>
> SUBROUTINE x()
> PRINT *,'Inside subroutine x'
> END SUBROUTINE x
You need a EXTERNAL x in the main program to make the above work.
Otherwise you are attempting to pass a real variable x into subroutine
sub, not a procedure.
W.
paul.rich...@gmail.com
Steve,
So the sentence
> "Two dummy arguments are distinguishable if neither is a subroutine and neither
> is TKR compatible (5.1.1.2) with the other."
should be taken as the only means of disambiguation and we should not
try to look for the other cases like subroutine/variable?
Thanks for the sudden feeling of enlightenment!
Paul
Steve Lionel
> So the sentence
>
> > "Two dummy arguments are distinguishable if neither is a subroutine and neither
> > is TKR compatible (5.1.1.2) with the other."
>
> should be taken as the only means of disambiguation and we should not
> try to look for the other cases like subroutine/variable?
Exactly. I agree with others that "procedure-ness" *could* be allowed
for disambiguation, but as the standard is currently written, it is
not.
Steve
Joost
> > should be taken as the only means of disambiguation and we should not
> > try to look for the other cases like subroutine/variable?
>
> Exactly. I agree with others that "procedure-ness" *could* be allowed
> for disambiguation, but as the standard is currently written, it is
> not.
I guess there is going to be some rule as to why this doesn't compile
(seems to require external for I), but I was thinking this could be a
counter argument, i.e. in the call to F I could be both a local
integer or an external function:
MODULE something
CONTAINS
SUBROUTINE F(I)
INTERFACE
INTEGER FUNCTION I()
END FUNCTION I
END INTERFACE
END SUBROUTINE
END MODULE
PROGRAM TEST
USE something, ONLY: F
INTEGER :: I
CALL F(I)
END PROGRAM TEST
INTEGER FUNCTION I()
END FUNCTION
Steve Lionel
> I guess there is going to be some rule as to why this doesn't compile
> (seems to require external for I), but I was thinking this could be a
> counter argument, i.e. in the call to F I could be both a local
> integer or an external function:
>
> MODULE something
> CONTAINS
> SUBROUTINE F(I)
> INTERFACE
> INTEGER FUNCTION I()
> END FUNCTION I
> END INTERFACE
> END SUBROUTINE
> END MODULE
>
> PROGRAM TEST
> USE something, ONLY: F
> INTEGER :: I
> CALL F(I)
> END PROGRAM TEST
>
> INTEGER FUNCTION I()
> END FUNCTION
This example does not illustrate an issue with generic
disambiguation. Here we have the case of argument matching and we
turn instead to 12.4.1.3 where it says:
"If a dummy argument is a dummy procedure without the POINTER
attribute, the associated actual argument shall be the specific name
of an external, module, dummy or intrinsic procedure."
That's why EXTERNAL I is required (or an interface declaring I as a
function.) This is pretty much the same as it has been since Fortran
77, at least, except that in F77 there was no way to tell the caller
that a dummy procedure was expected.
Steve
John Harper
Walter Spector <w6ws_xt...@earthlink.net> wrote:
>John Harper wrote:
>
>> module badsubs
>> ! implicit none intentionally omitted
>> contains
>> subroutine sub (x)
>> EXTERNAL x ! Illegal with the main program below?
>> call x () ! Legal since pre-F66
>> end subroutine
>> end module
>
Or else in the module before its "contains" if subroutine x was in
neither the main program nor the module. Or replace "EXTERNAL x" ,
in either of the places where it may appear, by an interface block for
subroutine x.
John Harper
Steve Lionel <steve....@intel.com> wrote:
>On Nov 7, 9:14 am, Joost <jv...@cam.ac.uk> wrote:
>
>> MODULE something
>> CONTAINS
>> SUBROUTINE F(I)
>> INTERFACE
>> INTEGER FUNCTION I()
>> END FUNCTION I
>> END INTERFACE
>> END SUBROUTINE
>> END MODULE
>This example does not illustrate an issue with generic
>disambiguation. Here we have the case of argument matching and we
>turn instead to 12.4.1.3 where it says:
>
>"If a dummy argument is a dummy procedure without the POINTER
>attribute, the associated actual argument shall be the specific name
>of an external, module, dummy or intrinsic procedure."
>
>That's why EXTERNAL I is required (or an interface declaring I as a
>function.)
And the interface must not be where Joost put it, inside subroutine F.
The following version of his program compiles, runs and prints 666.
Lines I have moved or amended or inserted are entirely in lower case:
MODULE something
interface
integer function i()
end function i
end interface
CONTAINS
SUBROUTINE F(I)
print *,i()
END SUBROUTINE
END MODULE
PROGRAM TEST
use something, only: f,i
CALL F(I)
END PROGRAM TEST
INTEGER FUNCTION I()
i = 666
END FUNCTION
Jugoslav Dujic
| MODULE something
| CONTAINS
| SUBROUTINE F(I)
| INTERFACE
| INTEGER FUNCTION I()
| END FUNCTION I
| END INTERFACE
| END SUBROUTINE
| END MODULE
|
| USE something, ONLY: F
| INTEGER :: I
| END PROGRAM TEST
|
| INTEGER FUNCTION I()
| ...
| Steve Lionel <steve....@intel.com> wrote:
|| That's why EXTERNAL I is required (or an interface declaring I as a
|| function.)
John Harper wrote:
| And the interface must not be where Joost put it, inside subroutine F.
| The following version of his program compiles, runs and prints 666.
| Lines I have moved or amended or inserted are entirely in lower case:
|
| MODULE something
| interface
| integer function i()
| end function i
| end interface
| CONTAINS
| SUBROUTINE F(I)
| print *,i()
| END SUBROUTINE
| END MODULE
|
| PROGRAM TEST
| use something, only: f,i
| CALL F(I)
| END PROGRAM TEST
|
| INTEGER FUNCTION I()
| i = 666
| END FUNCTION
I'm not sure if I misread your post, or you misread Joost's and Steve's...
Your example above and Joost's original example, quoteed below, are
*fundamentally* different in semantics despite superficial similarities.
To underline that, just change I to K here:
CONTAINS
SUBROUTINE F(K)
print *,K()
END SUBROUTINE
In your original example, interface to function I , and the dummy argument
I, are entirely different things -- the (implicit) declaration from inner
scope of F overrides the one from outer scope of SOMETHING. Put IMPLICIT
NONE into SOMETHING to see what I mean.
Your example works just because the semantics of
use something, only: f,i
is basically (for the purpose of this discussion) identical as
use something, only: f
INTEGER, EXTERNAL:: I
not "just" because the interface block is taken out to the module level.
It would work whenever the interface block is visible from the scope
of PROGRAM TEST.
John Harper
Jugoslav Dujic <jdu...@yahoo.com> wrote:
>Joost wrote:
>| MODULE something
...
>| Steve Lionel <steve....@intel.com> wrote:
>|| That's why EXTERNAL I is required (or an interface declaring I as a
>|| function.)
>
>John Harper wrote:
>| And the interface must not be where Joost put it, inside subroutine F.
>I'm not sure if I misread your post, or you misread Joost's and Steve's...
>
>Your example above and Joost's original example, quoteed below, are
>*fundamentally* different in semantics despite superficial similarities.
>In your original example, interface to function I , and the dummy argument
>I, are entirely different things -- the (implicit) declaration from inner
>scope of F overrides the one from outer scope of SOMETHING. Put IMPLICIT
>NONE into SOMETHING to see what I mean.
True. I was looking for ways to make the program compile and run with
minimal changes and with only one interface block or EXTERNAL statement,
and had not tried the effect of IMPLICIT NONE.