Steps Taken with "Start Debugging" (10.1)

[benjaminr_]

Hello,
I just lost a couple of hours to what I perceive is a behavior of Intel Fortran 10.1, and I want to see if my impression is true and if there is a workaround.

I am working on a program and a subroutine, each in its own file. While developing the subroutine, I changed the number of dummy arguments and calling arguments in the subroutine and calling program, respectively.

When I hit "F5" or the green "Start Debugging" arrow, I started to get compilation errors saying that I had the wrong number of arguments in my calling statement. Being inexperienced with some of the "fancy" techniques I was using (allocatable arrays), I went off on a tangent looking for some rules and workarounds that would let me pass allocatable arrays to subroutines.

Turns out, I just needed to "Rebuild" the entire solution. My assumption is that the IDE was only rebuilding one of the files (the one in focus?) when I used the "F5" shortcut.

In CVF, I thought the IDE picked up changed files and automatically rebuilt what was necessary. I would think the Intel IDE would do this as well.

Is my assumption correct and is there a way to get the Intel 10.1 IDE to automatically take care of rebuilding all changed files when I start to debug?

Thanks!

[Steven_L_Intel1]

I would expect it to recompile changed files automatically, exactly as CVF did. But the problem you had was likely due to the "generated interface checking" which CVF did not have, and depending on how you made changes, the generated interface might not have been recreated and an old one used. Doing a rebuild forced regenerating the interface module. We'll look at how we can improve this in the future.

[jarvusluntatintel]

Steve,

When I first switched to Intel, changed files would automatically recompile when I pressed F5. Somewhere along the way (I might have been experimenting with different compile/link options) this behavior stopped and changed files would not recompile automatically. The good news was debugging got much quicker. It had been taking 45+ seconds for the debugger to kick in. This dropped to a few seconds. Evidently not having to check 1000's of subroutines for changes made a big difference. I'm much happier with the new behavior and never tried to figure out what caused the change. However, when I occasionally forget to recompile before debugging, I can see the debugger "executing" comment lines because there is a mismatch. I would like to keep the "don't check for changes" before debuggingbehavior in future versions (unless it gets much, much quicker).

[Steven_L_Intel1]

The behavior I usually see is that if I ask to run a program that VS thinks is out of date, it asks me if I want to rebuild it. I have not seen the situation where starting debugging after changes are made does not ask this question. Looking at the Visual Studio options, I see Debugging > General > Require source files to exactly match the original version. Perhaps you have that unchecked?

I normally do a build (not a rebuild) after making source changes. That you got the error about argument mismatches tells me that VS is indeed recompiling changed sources. But I have seen the behavior you describe with code that looks like this:

...
call sub (args)
...
subroutine sub (args)

and I change the subroutine but not the call. What happens here is that the compiler does not notice when processing the call that the interface to sub might be recreated later on, if there is an existing interface. (If none, then it waits to do the check.)

[benjaminr_]

Just for clarification: I am using Intel Fortran 10.1 for Windows with the default VS2005 IDE.
As first installed, the IDE would ask if I wished to re-compile every time I changed a file and went right to debugging.
I checked the box "don't ask every time" and answered yes.

[Steven_L_Intel1]

Ok, that's the behavior I would expect.