Intel Fortran compiles and links the program every time I debug or run the program in VS 2005

Intel Fortran compiles and links the program every time I debug or run the program in VS 2005

One of the program I am working on has an irritating behaviour; every timeI want to run or debug the program in Visual studio 2005 or 2010, some of the files will compile and the program is linkedfirst. This happensevery time, evenwhen I have just compiled and linked the moment before (without any changes in any source file).

Other programs I use will debug/run immediately without compilation/linking.

Iam very interestedwhat the cause for this problem is!

(A window isopened every time telling me "THIS PROJECT IS OUT OF DATE!)
I use Intel Fortran 11.1 and 12.3.175)

6 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

This happens when your Solution and/or Projects within a solution has circular dependencies (A depends on B, B depends on A), (A depends on B, B depends on C, C depends on A), ...

A common cause for this is when module files cross reference with other module files.

module A
USE B
...
-------------
module B
USE A
...

Change to something like

module commonAB
(common data)
(cross usedinterfaces)
--------------------------
module A
USE commonAB
... (prior A data sans commonAB data)
-------------------
module B
USE commonAB
... (priorB data sans commonAB data)
-------------
subroutine yourSubroutinie()
USE A
...

Jim Dempsey

www.quickthreadprogramming.com

Oh, thanks a lot! I think it is correct; we have a circular reference. Now I will try to fix.

Am I correct that the situation that is described here is comform the situation of par. 13.2.4 (pag 248) of Metcalf c.s. "Fortran 95/2003 explained" and that this case of circular dependenciescan be handledwiththe submodule feature (once it is available in the compiler)?

Robert

>>circular dependenciescan be handledwiththe submodule feature (once it is available in the compiler)?

Why wait. You can make a dependency tree nowinstead of a list which can generate circular dependencies.

In an unusual example were you have co-routines where subroutine/function A in modA references subroutine/function B in modB and subroutine/function B in modB references subroutine/function A in modA then the tree solution is to create modInterfacesAB containing the interfaces and/or inter-module common (shared) variables. modA and modB then USEs modInterfacesAB instead of each other. The amount of work in makeing this division could be on the order of time spent writing these forum posts on this subject.

Don't wait for a "magic" solution (sub modules) as the work to modify your code to use the sub-modules will likely exceed the work to make the dependency tree. When designing a new app then sub-modules may make more sense.

Jim Dempsey

www.quickthreadprogramming.com

Thanks Jim,

at present I do not have a problem of this type. I made the remark because I found it in the new Fortran 2008 features and felt the submodule feature an elegant one to solve this circular dependency cases. Nevertheless,once there comes something like this onmy table I will certainly take a close look at your suggestion.

Best regards,
Robert

Leave a Comment

Please sign in to add a comment. Not a member? Join today