/fpp interferes with breakpoints/stepping through code - again

/fpp interferes with breakpoints/stepping through code - again

I have a problem with stepping through the code when fpp is used and there are #ifdef directives in the code. Similar problem has already been reported two years agowith earlier versions of VS and Fortran. Now I have VS 2008 installed on 64-bit Windows 7 and the Fortran compiler 11.1.051 but the symptoms seem to be similar. Namely, one cannot set a breakpoint in some parts of the codeand/or stepping in to functions/subroutines does not move the pointer into theright code.The lines shown/pointed to by the debugger are obviously NOT the ones which are executed.

Does anybody know if there is a fpp option which could solve that problem?

Jozef

10 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You could save the pre-processed code, and build that in debug mode, then watch the execution of the pre-processed source. I agree this would fall short of ideal.

If you have an example you can share, we can try and figure out what might have gone wrong with the line number correlations.

Either attach it here, or submit through Premier.

thanks -

- Lorri

Quoting - Lorri Menard (Intel)

If you have an example you can share, we can try and figure out what might have gone wrong with the line number correlations.

Either attach it here, or submit through Premier.

thanks -

- Lorri

The problem is that it is a huge program used for analysis of experimental data. It consits of a couple of hundreds of c and fortran programs. In addition, in order to test it, you should also have some experimental data. Altogether it would occupy ~2 GB.If you are not affraid then I can zip the whole project and some data and send it to you.I guess sending you just that subroutine where I see the problem would not be enough.

By the way I've discovered one more bug.If breakpoint is set on an instruction like n=n+1 then the instruction is not executed, i.e., n remainsunchanged.

Jozef

Quoting - tim18
You could save the pre-processed code, and build that in debug mode, then watch the execution of the pre-processed source. I agree this would fall short of ideal.

Thanks. The problem is that it is a huge program so it would require quite a lot of time to replace fortran program with those produced by the preprocessor. Therefore, to debug a subprogram I remove all #ifdef lines and leave only the code which is to be executed. Then it works. I'm really looking forward for a new upgrade free from those "little" inconveniences.

Jozef

Quoting - Jozef

Thanks. The problem is that it is a huge program so it would require quite a lot of time to replace fortran program with those produced by the preprocessor. Therefore, to debug a subprogram I remove all #ifdef lines and leave only the code which is to be executed. Then it works. I'm really looking forward for a new upgrade free from those "little" inconveniences.

Jozef

Jozef,

Several years ago I experienced the same problem (I think it was on V8.n.n, or may have been an early V9.n.n version).

What I found as a interrum work arround that could keep the #if/#endif statements was to breakup a large source file into multiple smaller source files. If the file had multiple subroutines, the first step was to place each subroutine into a seperate file. For files with a singlelarge subroutine, break the large subroutine at non-performance critical parts. Although this was cumbersom, it was easier to do than removing/reinserting the #if/#endif statements. And, later, when the problem is fixed, you can use this code witout changes.

Jim Dempsey

www.quickthreadprogramming.com

We routinely build large projects with a Makefile + perl script system which automatically splits the source down to single function files, pre-processes them before compilation, and has the option to leave the pre-processed source in the build directory. It also accepts lists of individual functions to be compiled with a different level of optimization. One advantage is the build time with Intel compilers is less than half what it would be with full optimization throughout. The difference on the compilers for which it was set up originally was several times that.
Needless to say, it's more difficult to make it work on Windows, and more difficult with C than Fortran (it is generally used for mixed languages). Recent multicore race bug corrections in cygwin should improve the situation.
Debugging has to be done with the pre-processed sources, as the relationship to the original sources has been hidden from the compiler intentionally. So, there is an intentional restriction against too fancy pre-processing transformations, and the "antiquated" style leaves little reliance on inter-procedural optimizations (which don't work well on a very large project which isn't structured specifically to facilitate them).

Quoting - jimdempseyatthecove

Jozef,

Several years ago I experienced the same problem (I think it was on V8.n.n, or may have been an early V9.n.n version).

What I found as a interrum work arround that could keep the #if/#endif statements was to breakup a large source file into multiple smaller source files. If the file had multiple subroutines, the first step was to place each subroutine into a seperate file. For files with a singlelarge subroutine, break the large subroutine at non-performance critical parts. Although this was cumbersom, it was easier to do than removing/reinserting the #if/#endif statements. And, later, when the problem is fixed, you can use this code witout changes.

Jim Dempsey

Jim,

Thanks. Your trickworks with version 11 as well. However, I find it annoying that in order to use a commercial product one has to use some tricks to get it working!

Jozef

Quoting - Jozef

Jim,

Thanks. Your trickworks with version 11 as well. However, I find it annoying that in order to use a commercial product one has to use some tricks to get it working!

Jozef

Jozef,

I didn't like to do that either since I prefer to see the large context of things in one spot. I am glad for you that this technique works for you.

Jim Dempsey

www.quickthreadprogramming.com

Quoting - Jozef

The problem is that it is a huge program used for analysis of experimental data. It consits of a couple of hundreds of c and fortran programs. In addition, in order to test it, you should also have some experimental data. Altogether it would occupy ~2 GB.If you are not affraid then I can zip the whole project and some data and send it to you.I guess sending you just that subroutine where I see the problem would not be enough.

By the way I've discovered one more bug.If breakpoint is set on an instruction like n=n+1 then the instruction is not executed, i.e., n remainsunchanged.

Jozef

OK, generally speaking, we prefer small, concise examples, but anyone who has seen commercial Fortran applications know that in real life they're often huge and complex :-)so we're not afraid of those. We just like the little ones better.

However, in this case, all *I*'d like to see is the subroutine that's giving bad line numbers, a pointer to which line numbers are bad, and enough include files/mod files/etc so that I can compile the source file.

Now, about your other bug ... I can't imagine that setting a break would have an effect on the executable code. I'm much more suspicious of bad line number correlation, and that where you think you're setting a breakpoint, and where the code thinks you're settinga breakpoint, does not match.

thanks -

- Lorri

Leave a Comment

Please sign in to add a comment. Not a member? Join today