- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I currently have code that uses multiple modules. It is compiled using 'ifort -o NameOfFileContainingModule1 ...Module2 ... main.f90'. I have no idea whether the order in which the modules are listed in compiler command matters. Does it? And what are the criteria for placing them there?
Thanks.
Markus
I currently have code that uses multiple modules. It is compiled using 'ifort -o NameOfFileContainingModule1 ...Module2 ... main.f90'. I have no idea whether the order in which the modules are listed in compiler command matters. Does it? And what are the criteria for placing them there?
Thanks.
Markus
Link Copied
9 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Placement on the command line determines order of compilation. The order of the files on the command line needs to match USE usage.
For example, if the main program depends on module2, and module2 depends on module 1, to ensure the .mod files are present you must list them on the ifort command line as follows:
ifort module1.f90 module2.f90 main.f90
If you use individual ifort command lines for each source file, they must be executed in the order that matches the USE usage. For the example above, the ifort commands must execute in the same order as the files are listed above.
When the compilation order does not match the USE usage, the compiler issues an error like:
fortcom: Error: module2.f90, line 2: Error in opening the compiled module file. Check INCLUDE paths. [MODULE1]
use module1
----^
compilation aborted for module2.f90 (code 1)
For example, if the main program depends on module2, and module2 depends on module 1, to ensure the .mod files are present you must list them on the ifort command line as follows:
ifort module1.f90 module2.f90 main.f90
If you use individual ifort command lines for each source file, they must be executed in the order that matches the USE usage. For the example above, the ifort commands must execute in the same order as the files are listed above.
When the compilation order does not match the USE usage, the compiler issues an error like:
fortcom: Error: module2.f90, line 2: Error in opening the compiled module file. Check INCLUDE paths. [MODULE1]
use module1
----^
compilation aborted for module2.f90 (code 1)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Kevin Davis (Intel)
Placement on the command line determines order of compilation. The order of the files on the command line needs to match USE usage.
For example, if the main program depends on module2, and module2 depends on module 1, to ensure the .mod files are present you must list them on the ifort command line as follows:
ifort module1.f90 module2.f90 main.f90
For example, if the main program depends on module2, and module2 depends on module 1, to ensure the .mod files are present you must list them on the ifort command line as follows:
ifort module1.f90 module2.f90 main.f90
I currently have a project that has 'unused' dependencies, eg, main depends on module2 and module2 has a 'USE' for module1 and module3 but actually only calls subroutines found in module1 (only main calls subroutines from module3).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, the order of the USE statements dictates the order the compiler searches for the corresponding .mod files. The compiler requires the .mod file be present for every module appearing in a USE. It does not matter what if anything is used from the module. The compiler does not do any call analysis of actual uses of module components beyond the USE statement when determining the requirement for the .mod file in the using routine.
In the project you described, the unused dependency dictates that you compile in the following order: module1, module3, module2, main
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Kevin Davis (Intel)
Yes, the order of the USE statements dictates the order the compiler searches for the corresponding .mod files. The compiler requires the .mod file be present for every module appearing in a USE. It does not matter what if anything is used from the module. The compiler does not do any call analysis of actual uses of module components beyond the USE statement when determining the requirement for the .mod file in the using routine.
In the project you described, the unused dependency dictates that you compile in the following order: module1, module3, module2, main
My example with:
main.f90 : USE mod2, USE mod3
mod2: USE mod1, USE mod3
Start with main, follow the first USE until the 'used' modules don't 'use' any further modules, use the order in the last level (in my example mod1, mod2) then go back up one level and use the order there. Wow, this can get convoluted pretty quick (and easily result in circular dependencies). Are there some resources describing this in more detail? I searched through Metcalf's book and the Intel compiler documentation but could find such a basic description as you gave here.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, it can get confusing. I am not aware of any references, others might be. The Intel Fortran Users guide discusses using modules and states the requirement rather succinctly as:
You need to make sure that the module files are created before they are referenced by another program or subprogram.
It is not that straightforward to create a circular dependency. You could step into one if you do not remember to remove existing .mod files and you add a USE that results in a circular dependency; however, the nice thing is that the compiler catches and reports that.
For example, given moduleA.f90 and moduleB.f90 below.
moduleA.f90
========
[plain]module A use B end module[/plain]
moduleB.f90
========
[plain]module B contains subroutine C #ifndef NoA use A #endif end subroutine end module[/plain]
If you compile as shown, you will receive the error shown when recompiling module B:
$ ifort -c -fpp -DNoA moduleB.f90
$ ifort -c moduleA.f90
$ ifort -c -fpp moduleB.f90
moduleB.f90(7): error #7765: FATAL ERROR - conflict or recursive module USE
end subroutine
^
compilation aborted for moduleB.f90 (code 3)
The example above comes from another bug report about the recursive use causing an internal compiler error. If you try this example and see the internal compiler error, please know it is already fixed in an upcoming 11.0 update.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - rreis
The best way to deal with this is to use a Makefile
I understand. But just another question, from my limited tests I gather that if one file has several USE commands, the inclusion order does not matter during compilation. For example, both these options seem to work:
main.f90: use mod1, use mod2
ifort mod2.f90 mod1.f90 main.f90
ifort mod1.f90 mod2.f90 main.f90
Is this correct?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is correct. Module inclusion order (meaning, ordering of the USE statements) does not dictate compilation order so long as none of the USE statements lead to any inner dependencies as discussed earlier.It is the inner dependencies that dictate compilation order. If there are any, then you will know about it and suffer an error about opening the required module file.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The order of USE within a program unit is not important. What is important is that before the compiler sees a USE, the module named in that USE must have been already compiled, whether in a separate source file or earlier in the same source file.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page