permanently out of date source

[andrew_4619]

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.

[jimdempseyatthecove]

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.

Jim Dempsey

[IanH]

Historically (pre-submodule support) this was a symptom of circular module dependencies.

[andrew_4619]

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.....

[jimdempseyatthecove]

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.

Jim Dempsey

[andrew_4619]

Copied the sources to a new location and made a new project but the behaviour is unchanged :-(

[Steven_L_Intel1]

If you can provide a zip of a project that shows this, we'll be glad to investigate.

[andrew_4619]

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.

[andrew_4619]

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?

[Steven_L_Intel1]

No, there is no way to see what it thinks the dependencies are. We've found and fixed similar issues in the past, but really need a test case if a problem remains.

[jimdempseyatthecove]

Andrew,

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:

specification-part

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.

Jim Dempsey

[andrew_4619]

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!

[andrew_4619]

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. 

[jimdempseyatthecove]

>>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).

Jim Dempsey

[andrew_4619]

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.....

[FortranFan]

andrew_4619 wrote:

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.

[Steven_L_Intel1]

Intel Premier Support is the preferable way to share large files.