I've just stumbled across this error when compiling a bit of code that I've been using without problems for ages now. I'm using Gfortran 8.2 on Linux and I suspect that a compiler update has caused the issue.
When I define an interface with an optional argument that has a different number of non-optional arguments, Gfortran complains that the interface is ambiguous. For example, if I compile the following, I get "Ambiguous interfaces in generic interface 'test' for ‘testinit1’ at (1) and ‘testinit2’ at (2)":
module test_mod
implicit none
interface Test
module procedure test1, test2
end interface
contains
function test1(opt) result(rslt)
integer :: rslt
integer, optional :: opt
rslt = 1
end function
function test2(data, opt) result(rslt)
integer :: rslt
integer :: data
integer, optional :: opt
rslt = data
end function
end module
If I remove the optional argument opt, then it compiles fine. If I add a data argument to test1 that has a different rank to test2's data, then it compiles fine. If I add another non-optional argument to both functions, I get the same error message.
The actual code I stumbled across in is the Result interface in this file, which, as I say, used to compile as expected.
Any help appreciated!
Gfortran complains that the interface is ambiguous
Well, that's because the interface is ambiguous.
Which procedure should be chosen in the following call?
integer :: param
print *, Test(param)
test1 with the argument opt opted-in? Or...
test2 with the argument data passed and opt opted-out?
If it started to fail only after an update, that was probably a very welcome bug-fix.
If I remove the optional argument opt, then it compiles fine. If I add a data argument to test1 that has a different rank to test2's data, then it compiles fine.
Makes sense. Without the optional argument, both functions are completely unambiguous by number of arguments. Changing the rank of the argument also cause differentiation.
If I add another non-optional argument to both functions, I get the same error message.
Same problem. If both functions had an extra non-optional argument with type-kind-rank conformance, how would you resolve the call?
Suppose the new argument is data_extra:
print*, Test(param1, param2)
test1 with the argument data_extra passed and opt opted-in? Or...
test2 with the arguments data and data_extra passed and opt opted-out?
Related
I have a FORTRAN code with a routine:
SUBROUTINE READ_NC_VALS(NCID, RECID, VARNAME, VARDATA)
integer ncid, recid
character*(*) varname
real*8 vardata
dimension vardata(15,45,75)
etc.
I want to add some flexibility to this code, and I thought I would do it by first adding an optional flag argument:
SUBROUTINE READ_NC_VALS(NCID, RECID, VARNAME, VARDATA, how_to_calculate)
! everything the same and then ...
logical, optional :: how_to_calculate
Now, at this point, I am not even using "how_to_calculate". I am just putting it into the code for testing. So I compile the code without a hitch. Then I run it, and I get an error in the subroutine. Specifically, some of the values in the code later on are "magically" altered from what they were without that optional argument. The new values don't make sense to the logic of the code, so it exits politely with an error message. Let me stress again that at this point, I am not even using this optional argument. So then, on a lark, I go back to all the places in the source that call this routine and, even though my new argument in optional, I put in values for it in all the calls. When I do that, the code runs fine. So, what's up? How can the mere presence of an unused optional argument in a subroutine result in other data being corrupted? And how can adding input parameters for this optional argument fix things again? This is being compiled with PGI, by the way.
Any ideas? Thanks.
BTW, sorry for not providing more code. My boss might not be too happy with me if I did that. I don't make the rules; I just work here.
Optional arguments in Fortran are implemented by passing 0 (a null pointer) for each optional argument that has no value provided by the calling subroutine. Because of this subroutines that take optional arguments have to:
either have an explicit INTERFACE definition inside the calling subroutine
or be a module-level subroutine (for them interfaces are generated automatically)
If you add an optional argument to a subroutine but it neither has an interface in the caller or is not a module-level subroutine, then the compiler will not generate the right calling sequence - it will pass less arguments than expected. This could pose a problem on Unix systems, where PGI passes the length of all CHARACTER*(*) arguments at the end of the argument list (on Windows it passes the length as the next argument after the address of the string). One missing argument would shift the length arguments placement in the stack (or put them in the wrong registers on x64) leading to the incorrect length of the VARNAME string being received by READ_NC_VALS. This could lead to all sorts of ill behaviour, including overwritting memory and "magically" changing values that should not change according to the program logic.
Obviously, just adding a dummy argument to a subroutine, with or without the optional attribute, shouldn't cause any problems. What might happen, though, is that the change exposes some other problem with the code, which was already there, but didn't cause any visible bad effects.
Without any more code, all we can do is guess, which usually isn't really useful.
One thing that pops into mind is the necessity of an explicit interface, when using optional arguments. Is the code organized into modules?
I'm trying to teach myself Fortran, and have been messing around with linking multiple files together. Following examples, I have been writing programs in one file, functions in another, and using interface blocks in my main program to refer to the external function.
I was testing how much information was needed in the interface block and realised that I can remove it entirely.
My program:
program test
implicit none
real :: x, y, func
x = 3
y = func(x)
print *, y
end program test
And the function file:
function func(x)
implicit none
real :: x, func
func = x**3
end function func
I then compile it using gfortran -o test test.f90 func.f90 and the code works as expected. My question is, why do I not need to include an interface block in my program file? Is it simply a matter of good practice, or does defining func as a real variable serve as shorthand? I am on Windows, having installed gfortran through minGW.
As an aside/related question, if I instead use a subroutine:
subroutine func(x,y)
implicit none
real :: x,y
y = x**3
end subroutine func
And change the line y = func(x) to call func(x,y) then the code will work fine without any interface block or declaration. Why is this?
The declaration real :: func in the main program here declares func to be a function with (default) real result. This function has an interface in the main program as a result, so it is legitimate to reference that function with y = func(x).
The interface in this case is implicit. In this way, the main program knows exactly three things about func:
it is a function (with that name);
it has the external attribute;
it has real result.
The reference to the function is compatible with that knowledge. Further, how you reference the function matches precisely the properties of the function itself.
Equally, in the case of the subroutine, a call func(x,y) tells the main program exactly three things, again with the implicit interface:
it is a subroutine (with that name);
it has the external attribute;
it takes two real arguments.
Those three things again match the subroutine's definition, so things are fine.
Loosely, then, you don't need an interface block in these cases because the implicit interfaces are good enough.
There are times when an explicit interface is required and in most (nearly all) cases an explicit interface is better. As you can see in other questions and answers, there are usually better ways to provide an explicit interface than using an interface block.
Why do I not need to include an interface block in my program file?
Since Fortran 90, the recommended way to define reusable functions and subroutines is to use modules.
module func_m
contains
function func(x)
implicit none
real :: x, func
func = x**3
end function func
end module func_m
Then write use func_m in the main program, before implicit none: gfortran -c func_m.f90, gfortran -c test.f90 and gfortran -o test test.o func_m.o.
When you use modules, the compiler will check the type of the arguments of the functions. You also do not need to declare real :: func as the declarations are taken from the module.
When you compile as a "simple" object file, the compiler will simply call whatever function is named func without verification, as long as such a function is given in an object file.
The interface block is a kind of "in between". In your case, you could add one in the program file. This would force you to follow that declaration in the program. But it will not prevent linking to wrong functions at link time: there is no guarantee that the interface is right. It is mostly useful if you need to call C or FORTRAN 77 code from someone else, for which you couldn't use modules.
And change the line y = func(x) to call func(x,y) then the code will
work fine without any interface block or declaration. Why is this?
The interface issue is orthogonal to the function vs subroutine issue.
There are some cases where interface blocks are needed. For example if the called subroutine uses a pointer, allocatable or assumed shape arrays (this list is not complete, see the standard for more):
integer, pointer :: x(:,:) ! pointer attribute
integer, allocatable :: x(:,:) ! pointer attribute
integer :: a(:,:) ! assumed shape array
The pointer/allocatable have the advantage that the called subroutine can allocate it for the calling function. Assumed shape arrays automatically transfer the dimensions to the called subroutine.
If you use any of this your program will crash without explicit interface. Easiest solution is like said in the other answer: use modules to have the interface automtically correct. We use a perl script automatically extracting interfaces to have interface check without rewriting the code to modules (and avoid long compile times until all compilers reliably support Fortran 2008 submodules...)
My understanding of programming is very limited so I hope I am making sense.
I made a change to a fixed variable in a program (the program is called NAFnoise; I was using the .exe but it came with the source code and I made the change there). The program is written in Fortran and is in multiple files. I am using gfortran to compile it and most of the files works without a problem. One file, however, is giving me trouble. And I didn't even make changes to it. It is giving error messages that is like this:
error: 'x' argument pf 'dtime' intrinsic at <1> must be of kind 4
The same message appears for etime. The only times those (I am guessing they are) functions and variables inside them are referenced as shown below:
IMPLICIT NONE
! Local variables.
INTEGER(4) :: klo,khi,i,n_in,nvar,nj,j1,j2,ivar,nok,nbad
REAL(DbKi) :: kk2, Isumwell, Isum, Itot,eps,h1,hmin
REAL(DbKi) :: ys1,ys2,poverall,phipot
REAL(DbKi) :: bigben(2),bigben2(2),dtime,etime
REAL(DbKi) :: phif(10)
COMPLEX(DbKi) :: value,dval1,dval2,dval11,dval12,dval22
COMPLEX(DbKi) :: btrans,btrans1,btrans2,btrans11,btrans12,btrans22
COMPLEX(DbKi) :: bbb,bbb1,bbb2
and
write(*,*) etime(bigben2),dtime(bigben)
and
write(*,*) etime(bigben2),dtime(bigben)
I am guessing the program was found when the author included it in the source folder, so I am not sure what went wrong. The variable I change should have nothing to do with this. Does it have something to do with the compiler? How can it be fixed?
DTIME is a non-standard GNU function described in the manual https://gcc.gnu.org/onlinedocs/gfortran/DTIME.html. It requires an argument to be of kind 4. That is the single precision under the default settingd for gfortran.
Probably, DbKi means double precision instead for you. Change
REAL(DbKi) :: bigben(2),bigben2(2),dtime,etime
to
REAL :: bigben(2),bigben2(2)
(or real(4)) if you use the GNU intrinsic extension.
If you actually want to call some your own external dtime, you must declare an interface block for it.
The same holds for etime from https://gcc.gnu.org/onlinedocs/gfortran/ETIME.html
I have a parameter being declared in a fortran header file like this:
parameter (param=((0-565)))
param always seems to be valued at 565. Basis tutorials on parameters don't include information about what the ((0-565)) actually means in this context and my google-fu isn't up to this challenge.
The code
program main
implicit none
integer :: param
parameter (param=((0-565)))
! integer, parameter :: param = -565 ! suggest replacing two lines above with this
print*,"param =",param
end program main
sets param to -565, as confirmed by both g95 and gfortran. The comment line uses a suggested modern syntax, assuming param is of the integer data type.
I'm currently toying around with passing functions as arguments.
In the program below I use the built-in function EXP as an argument for
the integral function. My compiler gives me the following error:
integrate1.f90:22.26:
r = integral(-1.0,1.0,EXP,1000);
1
Error: Expected a procedure for argument 'f' at (1)
If I uncomment the usage of EXP on the declaration of the variable r I don't get this error.
So it seems that if I don't use a built-in function I cannot use it as an argument
which is kind of weird, cause "built-in" kind of suggests the function is loaded no matter what.
How can I prevent this error without explicitly using the EXP function? Do I need to use the USE statement to load built-in's? If there is no other way around this, I would be interested to know if this is due to the Fortran specification or a compiler issue?
I am using GNU Fortran (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3.
Example:
MODULE MINTEGRATE
CONTAINS
FUNCTION integral(from,to,f,n)
INTERFACE
FUNCTION f(y); REAL, INTENT(IN) :: y; END FUNCTION
END INTERFACE
REAL :: from,to,integral,width;
INTEGER :: n;
width=ABS(to-from)/n;
integral = 0.0;
DO i=0,n
integral = integral+f(from+width*i)*width;
END DO
END
END
PROGRAM INTEGRATE
USE MINTEGRATE;
!PROCEDURE(EXP), POINTER :: f => EXP; ! using the variable f below works without error
REAL :: r!=EXP(0.0);
r = integral(-1.0,1.0,EXP,1000);
WRITE(*,*) r;
END
"When an intrinsic function is passed as an actual argument to a procedure, its specific name must be used, and when called, its arguments must be scalar. Not all specific intrinsic functions can appear as actual arguments. (For more information, see Intrinsic Functions Not Allowed as Actual Arguments)." From Intel Fortran manual.
You were lucky, because the specific name of the generic exp for single precision real is also exp, but otherwise be careful and pass the right specific function, or write own wrapper calling the generic name. For example, if you wanted default real logarithm, you would have to use alog.
You can inform the compiler that you mean the intrisic function exp by:
intrinsic exp
placed among the declarations in the main program.