According to MFE p.74 “No ordering of modules is required by the standard, but normal practice is to require each module to precede its use. … [This practice] is required by many compilers.” I found that gfortran and ifort won’t compile the program below, which would seem to be standard-conforming. Does any compiler accept it and print 'In subroutine test2' ?
! Must used modules be in the right order?
module mod1
use mod2,only:test2
contains
subroutine test1
call test2
end subroutine test1
end module mod1
module mod2
contains
subroutine test2
print *,'In subroutine test2'
end subroutine test2
end module mod2
program test
use mod1
call test1
end program test
Should the standard specify that a module is not available if it appears after its USE statement? The F2008 = F2023 wording seems to have misled the three authors of MFE if Kargl is right. All four of them are of course renowned Fortran experts.
It is not a requirement of the standard that all modules contained in a single file be compiled in the order provided. The standard says nothing about files or compilation. So what then does it mean to the standard for a module “to be available”?
Now of course in practice it’s true every processor in common usage is a compiler, and they compile the contents of a file in order. I would say that yes, MFE is a bit optimistic with that statement, but not technically wrong.
The sentence you quoted from MFE says that it is not required by the standard for a processor to compile it correctly. In practice, as you noted, most compilers will not compile it when the source file is in a clean directory. Even worse, if for some reason there is an existing mod2.mod file sitting around, then that is the file that will be used when module mod1 is compiled. If the actual module mod2 has changed since the previous mod2.mod file was created, this can result in strange errors. Then the next time you try to compile module mod1, it might then work, because there is now a new correct mod2.mod file in the directory.
Indeed. I have found sometimes that if I compile a program with gfortran, then ifort won’t compile it unless I delete all the relevant .mod files and then try ifort again. I didn’t need that workaround when compiling first with ifort then with gfortran. Sorry, I haven’t isolated exactly what feature of the offending program caused the problem.
The word “optimistic” has appeared here in the context of MFE, but please note another term, “a stretch”, can be introduced here to view this as standard-conforming on the basis of MFE!
Please also note from a practical point-of-view with actual projects (where modules are better off in separate files) and Intel Fortran and Windows OS and Microsoft Visual Studio IDE (you will know no licensing needed for most nonprofit domains including educational institutions), a user can just add all the files to a Visual Studio project in any order which the IDE then displays in alphabetical order and then at build time, the Intel Fortran integration parses and compiles them usually in the right order.
You can then add -gen-dep compiler option to generate a listing you can use with other processors, say like so:
Anyone know why or how this would work? How can gfortran use *.mod files created with ifort?
It is typical when switching compilers to clean all of the *.mod and *.o files first. With the make build utility, for example, one would typically define a clean: target that does that. So the sequence “make clean” and then “make” would be executed when switching to a new compiler.
