I am making some tests with PSXE16.0 using SUBMODULES. My test job exhibits some strange behaviour:
1] On doing a successful build or clean then build if I do F5 to debug it says the exe is out of date and does a full build again. It will then debug.
2] On changing anything, e.g. the main program (there are only 3 source files ) is does a complete rebuild every time.
This type of behaviour I have experienced before when the project has circular dependencies. This project has three files, a module file with interfaces, a sub module file with only contained sub-routines and a simple main program. I did all the usual close VS and restarting, deleting the project and making a new one etc.
On opening the project in VS the first time and doing a build I get (one time only!):
C:\Users\...\fred_subs.f90 : warning: Module 'Debug\subroutine.mod' is created by both 'C:\Users\...\fred_subs.f90' and 'C:\Users\...\fred.f90'. 1>------ Build started: Project: SUBM_TEST2, Configuration: Debug Win32 ------ 1>Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]... 1>fred.f90 1>fred_subs.f90 1>SUBM_TEST.f90 1>Linking... 1>Embedding manifest... 1> 1>Build log written to "file://C:\Users\.....\Debug\BuildLog.htm" 1>SUBM_TEST2 - 0 error(s), 0 warning(s) ========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========
Note the first line! I think this is the route cause but it makes no sense are the VS integration picking up “module subroutine” which is part of the interfaces for each subroutine and also the definition and believing there is a MODULE called SUBROUTINE? “Subroutine.mod” is not created by the way.
Does anyone know of any issues like this?
Thank you for the extra time to create the reproducer. I do not recall hearing about such behavior during our 2016 Beta or recently following the new 2016 release. I will try your test case and see how it behaves for me.
Which version of Visual Studio are you using?
! fred.f90 module billy implicit none public integer, parameter :: axs6_irk = kind(1.D0) ! real kind for dp integer, parameter, private :: irk = axs6_irk INTERFACE MODULE FUNCTION IS_LEAP_YEAR(IYEAR) INTEGER(KIND=2), INTENT(IN) :: IYEAR LOGICAL(KIND=4) :: IS_LEAP_YEAR END FUNCTION IS_LEAP_YEAR MODULE SUBROUTINE DVCUNIT(VU,V) REAL(KIND=IRK) :: VU(3) REAL(KIND=IRK) :: V(3) END SUBROUTINE DVCUNIT END INTERFACE END MODULE billy !fred_subs.f90 submodule (billy) fred_subs contains module function is_leap_year(iyear) ! returns true if iyear is a leap year and false otherwise implicit none logical(4) :: is_leap_year integer(2), intent (in) :: iyear if (mod(iyear,400_2) == 0) then ! special case for every 4th century is_leap_year=.true. elseif (mod(iyear,100_2) == 0) then ! centuries are not leap years is_leap_year=.false. elseif (mod(iyear,4_2) /= 0 ) then ! not divisible by 4 and not special case so not a leap year is_leap_year=.false. else is_leap_year=.true. ! divisible by 4 and not a special case to leap year endif end function is_leap_year module subroutine dvcunit(vu,v ) implicit none REAL(irk) :: VU(3), V(3) vu = v/norm2(v) end subroutine dvcunit end submodule fred_subs ! SUBM_TEST.f90 program SUBM_TEST use billy implicit none logical(4) :: isleap integer(2) :: iyear real(8) :: x(3), y(3) iyear = 1984_2 isleap = IS_LEAP_YEAR(IYEAR) X=1._8 call dvcunit(y,x) print *, 'Hello World' print *, y(1), y(2), y(3) end program SUBM_TEST
And if I comment out all bits that relate to "module subroutine dvcunit"
Then all the problems go away and we no longer think fred.f90 and fred_subs.f90 create a dependancy called subroutine.mod!!!!!!
An Additional put unrelated point of note "module function" and "Module subroutine" don't create a fold in the VS editor like "function" and "subroutine" do.....
I have been using VS2013 Update 5 as noted above. Using the source files from #2 I created a new solution and project in VS2010 shell.
I get the same problems with full rebuilds if anything changes or indeed if I want to run the debugger after a successful build. It sort of renders SUBMODULES pretty useless 😞
I am of the opinion it is a problem with the VS inegration for PSXE16..
Amusingly I also get a remark:
.... SUBM_TEST2\fred.f90(10): remark #7712: This variable has not been used.
That would be line 10 of the code in post #5! That warning should give a variable name but in this case it makes no sense at all!
Dear Intel, there is a simple test job on #2 please could you try this!
It might be a problem with my install but I am much more inclined to think it is an issue with PSXE16 integration in VS so I don't want to spend the time doing full uninstalls, cleanups and re-installation as this takes a lot of time!
The full rebuild I am getting all the time totally kills one of the main benefits of submodules.
I confirmed everything in your original post - list items , , and the first-time only error regarding two source files creating the same named module file. I also confirmed the behavior described in post #5. I agree this appear to be issue with our Fortran integrations. I evaluated using both MSVS 2013 and 2012.
I will report the integration issues and the lack of folding to the integration developers and update this post with the corresponding internal tracking ids.
I reported all the issues from posts #1, #5, #6 to Development. Thank you for reporting all these.
(Internal tracking id: DPD200375967 - Source code collapse/expand feature not active for subprograms in a submodule)
(Internal tracking id: DPD200375981 - One-time warning: Module '<some>.mod' is created by both... for project containing submodules)
(Internal tracking id: DPD200375984 - Submodules cause full project rebuild after source code edit unrelated to the module or submodule)
(Internal tracking id: DPD200375987 - Erroneous remark #7712 for submodule interface block)
(Resolution Update on 02/26/2016):
DPD200375984 - fixed in the Intel® Parallel Studio XE 2016 Update 2 Release (PSXE 2016.2.055/ CnL 2016.2.180 - Windows)
DPD200375987 - fixed in the Intel® Parallel Studio XE 2017 Initial Release (PSXE 2017.0.036/ CnL 2017.0.109 - Windows)
(Resolution Update on 10/24/2016):
DPD200375967 - fixed in the Intel® Parallel Studio XE 2016 Update 4 Release (PSXE 2016.4.062/ CnL 2016.4.246 - Windows)
DPD200375981 - fixed in the Intel® Parallel Studio XE 2017 Initial Release (PSXE 2017.0.036/ CnL 2017.0.109 - Windows)
Is there any update on this? The submodules feature, as advertised, will save us a lot of time.
Item 3 above: "Submodules cause full project rebuild after source code edit unrelated to the module or submodule)" is actually worse than that for us. It will recompile any file that has a module with submodules defined for it (and then anything dependent on that), even if no changes have been made at all.
The Visual Studio integration was mentioned. We're using VS2015. Maybe we just have a wrong setting or something?
There is no update on any of these at this time. I added you as another occurrence of the rebuild issue and included your comments in the internal tracking record. I also asked Development to update me on any progress and I will let everyone know what I hear.
...is actually worse than that for us. It will recompile any file
LOL, how can it be worse than rebuilding everything everytime?
Anyway is there any possibility the "build cascade" fix will be in update 1? I have abandoned 16.0 for 15 U4 but am looking forward to have sub-modules I can use. 🙂
Quote:firstname.lastname@example.org wrote:...is actually worse than that for us. It will recompile any file
LOL, how can it be worse than rebuilding everything everytime?
Since you asked ...
Rebuilding after unrelated edit = bad
Rebuilding after no changes at all = worse
It means I can't even run consecutive debug sessions without rebuilding in between.
That is exactly my experience also!
When you debug again after no actual changes ignore the warning about the exe being out of date and it will run the last built exe anyway.
"That is exactly my experience also!"
Now that I've re-read everything from the top, I can see that. If I appeared to be claiming to be worse off than you, it was unintentional. When I said that it was "actually worse than that for us", I was quoting the post directly above my first one. Anyway, the whole point of my posting was to ask if your problem had been fixed and, if not, to add another instance of someone reporting it because I do think that a fix here is very important.
Unfortunately, I guess I selected "Don't show me this again" in the warning popup at some point and I can't find the option in VS to reverse this. It's pretty much moot for now because we have decided to forgo coding with submodules until this issue is dealt with.
Please could you look at fixing the "horrendous" (A quote from FortranFan in another thread) build cascades we get with submodules soon. I have been a good boy this year. 🙂
I can offer that the issue is reportedly fixed but I don't have a build available yet to confirm that. I expect (and am pressing for) the fix to be available in the PSXE 2016 Update 2 (Q1 - 2016 timeframe). The rest is up to Santa.....