VS2013 strange behaviour/submodules/PSXE16.0

[andrew_4619]

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? 

[andrew_4619]

I made a short reproducer with three source files and the vfproj which is attached.

[Kevin_D_Intel]

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?

[andrew_4619]

VS2013 update 5

[andrew_4619]

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

[andrew_4619]

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!

[andrew_4619]

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.

[Kevin_D_Intel]

Yes, on the shortlist. Sorry for the delay.

[Kevin_D_Intel]

I confirmed everything in your original post - list items [1], [2], 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.

[andrew_4619]

Thanks kevin

[Kevin_D_Intel]

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)

[Thomas_R_]

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?

[Kevin_D_Intel]

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.

[andrew_4619]

thomas@enginia.com wrote:
...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. :-)

[Kevin_D_Intel]

Unfortunately the build cascade defect will not be fixed in Update 1. I will keep this thread updated on status as I learn it.

[Thomas_R_]

app4619 wrote:

Quote:

thomas@enginia.com 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.

[andrew_4619]

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.

[Thomas_R_]

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

[andrew_4619]

Dear Santa,

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

[Kevin_D_Intel]

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

[andrew_4619]

Thank you Santa!