- removed comment
Intel compiler complains wrongly about incompatible argument lists in Fortran
Issue #165
closed
On the CCT numrel workstations, the Intel compiler (with version and options as defined in SimFactory) sometimes complains that argument lists for calls in Fortran don't match. This usually happens to me in GRHydro.
The reason seems to be that the Intel compiler silently remembers the prototype of every Fortran subroutine it encounters, and then compares against this prototype (if it exists) when the subroutine is called. If a subroutine's argument list changes, and if the caller is then recompiled before the subroutine itself, then the compiler detects a mismatch (because it compares to the old argument list) and aborts with an error.
The Intel compiler stores the argument lists together with module information in the scratch directory. To solve this problem, one either has to clean the configuration (make -clean), or one has to manually delete all outdated .mod files belonging to this thorn (and possibly also delete all .o files of this thorn). A make -clean is expensive, and the manual solution requires in-depth knowledge of the problem.
Cactus should detect this problem and offer a solution, although I don't know which. Maybe the solution could involve compiling files in a different order by detecting the dependency between the caller and the callee, and treating this in the same way as module definitions.
Keyword:
Comments (5)
-
-
reporter
- removed comment
This is not an issue with modules; we figured out how to build with modules in Fortran. The Cactus make system pre-processes the Fortran files, looking for "include" and "use" statements, and then introduces the corresponding dependencies. Some people introduce these dependencies by hand, but this is in general not necessary.
The problem here is that the Intel compiler creates a pseudo-module for each source file, and checks these even without any use statements. For example:
file A.f90 contains subroutine A file B.f90 calls subroutine A
In this case, the Intel compiler acts as if file A defined a module, and as if file B used that module.
-
- removed comment
Is there an option to suppress those files?
-
reporter
- changed status to resolved
- removed comment
I believe there is; -nogen-interfaces should do the trick. Applied.
-
- changed status to closed
- edited description
- Log in to comment
This is a known problem of the make/fortran combination. make assumes that a target is always updated by a build rule. However, the module files might (depends on compilers) not be updated, even when the source file changes (as long as the interface is the same). Google for 'fortran modules make' and you find that we are not alone here, and there doesn't seem to be a simple and working solution.
GRHydro might of course also lack some dependencies in which case this should be fixed. But more information would be necessary for this to debug, parallel builds worked for me so far - which would be prone to errors like this.