I have a Fortran project that has quite a number of modules and some sub-modules. If I do a clean build it builds OK with no errors however if I change nothing and then do a build there is one particular sub-module file (the routines not the interfaces part) that always rebuilds and links. It doesn't build any dependencies of that module (though as the interfaces don't change it shouldn't anyway).
Has anyone got any clues as to what might cause this? Or how I can debug any spurious dependencies?
I am wondering if it is some lesser varient of the "sub-modules cause full rebuilds bug" that was fixed at the previous update. I have only built this varient of the project under the latest 2016 update 3 BTW.
Take a look at the date and time stamps of all the files (interface, main module, sub modules, both the .mod and the .obj). This is just a guess, I suspect that you have warn interfaces enabled and one or more interfaces the problem some sub module uses is re-generated following build of the sub module.
If you perform: clean, build, build
Then perform a DIR of all outputs to file,
Then perform: build
Assuming the unnecessary build took place
Perform the DIR of all outputs to file,
Then the differences in the time stamps will show what got built and in what (completion/close) order. This may be indicative of what is going on.
Did a clean build and looked at the build order. Then only one file is then re-compiled creating an obj and smod file. Only three source files come after this one in the build order and the spurious file has no dependancies on these files.
I think maybe a will create a new project and see if that fixes the problem.....
I seem to recall some discussion of an undocumented diagnostic option the emits the reason for a rebuild of a file. I may be wrong on this. Steve would know if such an option exists. And if such an option does not exist, it should be added to the wish list, as it would help diagnose problems like this.
Let us know if the new project corrects for this. FWIW, I've experience this issue (pre-sub modules) after an update of Parallel Studio. Recreating the Project file corrected the issue. In my case, it seemed to be a VS integration issue with an uninstall/install mucking up a project file.
I can't share the source. However, the 'rogue' file has module functions/subroutines for a sub module. So I have split it into 5 source files each being a sub-module of the same parent (interfaces) module. Three of the 5 parts rebuild every time after no changes but two parts do not!
By this method I suspect if I spent some time I would either find the flaw in my code or be able to make a reproducer. I have no time right now but will look at it in due course.
submodule (cadmc) cadmb_subs implicit none contains module subroutine dummer_and_dummer() integer :: i i=1 end subroutine dummer_and_dummer end submodule cadmb_subs
Moving on (but no solution) module cadmc has 5 sub-modules 3 of which are deemed to be permanently out of date. Amusingly only of these out of date submolules is one I made as a test shown above. dummer_and_dummer is not actually used in the project and clearly has no dependencies so how could it be out of date if cadmc is not out of date?
Is there any means of outputing what VS thinks the project inter-dependencies are?
If you are up for an experiment, in your above cadmb_subs, add:
real :: UnusedVariable
prior to the contains.
In the IVF documentation on sub-modules it states:
Is one or more specification statements, except for the following...
Your sample has zero specification statements.
Note, I am not making any declaration that zero specifications is not prohibited by standards specification. Rather guessing that the implementer (compiler code) may have coded to require one or more.
Hi cheers, keep that ideas coming. For the record that doesn't have any effect on how it behaves. I surmise that is poor wording in the ifort documentation as having no specification statements is valid. Any specification in the sub-module before the contains only has scope in that sub-module, specification statements in the parent module have scope across all the sub-modules of that module.
I am fairly convinced that there must be a bug in the dendancy checking but making a small reproducer is a problem.
I just discovered whilst doing a test further to your test that renaming the sub-module and the file it is in cured the 'bad dependancy' for that source:
submodule (cadmc) flibble implicit none real :: UnusedVariable contains module subroutine dummer_and_dummer() integer :: i i=1 end subroutine dummer_and_dummer end submodule flibble
the above is not now permanently out of date!
whilst on my favourite subject of SUBMODULES
error #7257: The characteristics of the procedure's arguments differ from those of the same procedure's arguments that are redefined in the INTERFACE statement. [RAD]
This error was because I had intent(out) in the interface and intent(in) in the module subroutine however the compiler attributes all such errors to line number 1 of the sub-module so you cant click through to the error line. I may have reported this previously but I think that was a similar but different error.
>>I just discovered whilst doing a test further to your test that renaming the sub-module and the file it is in cured the 'bad dependancy' for that source
Ok, this may be a clue.
Perform from CMD window
dir /s /b c:\cadmb_subs*.*
to see if there is an additional source, object, or mod file that is visible to the compiler. IOW you may have at one time located this file (or its outputs) in a different folder. And for some reason the dependency checker is tripping over those files (with older dates on outputs or newer date on source).
I think I will have to close this item in a rather unsatisfactory way :-(
To summarise my latest study on this:
1] copy all source files to new folder and make a new project. We still have a 'bad/hidden' dependency.
2] Create a new source file in the project with a unique new name. Cut n paste the source from the 'bad' submodule file, and for good measure give the submodule a new and unique name. Remove the old 'bad' submodule file and do a clean build.
The result is that the new file is still 'bad'. The conclusion I make is that it is something that is specifically in that source file that triggers the problem.
3] Create a new source and a new submodule. Cut and paste some routines from the bad to the new. Do a build. The bad file remains bad and the new file is OK.
4] repeat 3] several times. We 'smell a rat' when the bad file has been whittled from 150 routines to just one and is still bad, and that routine just happens (by random choice) to be the first contained routine in the bad file.
5] We copy the last routine from the bad file to the new file and remove the bad file from the project. Magically the problems have all gone away!!!!!!
I could say at this point that the new 'good' file is not the same as the old bad file, it has all the same content but the contained routines are not in the same order. That said that might not be the problem and it would take a long time to try to home in on that with the tools I have available.
I think there is a bug to be found somewhere but it probably has complex causes and as it has for me gone away I will ignore it until it comes back if ever.....
I think I will have to close this item in a rather unsatisfactory way :-( ..
Is it possible for you to share whatever files you have from this latest test privately with Intel Fortran team (Steve et al.)? This way, they get to see your problem without requiring you to share everything publicly and it might help them develop a resolution to the issue. Steve might be able to suggest to you a way to share the files, perhaps as simple as e-mailing him a zip of your folder.