Intriguing issue - Can someone provide me with an explanation?

[Christian_Ride]

Hi all,

I'm just looking for a possible reason to why this happens:

I have a program written in Fortran 77. When I compile it using Intel Fortran 10.0.023 on a Linux machine (running OpenSUSE 11.2), it runs fine. However, if I compile it with Intel Fortran Composer XE 2011 (update 2), I get a segmentation fault SIGSEV when I run the program. I can "resolve" the segmentation fault by recompiling the code using -g -traceback and then the program runs fine.

Any ideas on why this is the case? Why is it that by turning on the debugging options (-g -traceback) on Intel Fortran Composer XE 2011 (update 2) eliminates the SIGSEV error for the same code on the same platform, same distro...?

As far as I can tell (without doing extensive tests), the outputs from each program (one compiled in 10.0.023 and the other in XE 2011-update2) are identical.

Thanks,

Chris

[Steven_L_Intel1 · Accepted solution]

-g disables optimizations which can cause variables and code to be in different orders. You may be referencing uninitialized memory. First try just -traceback without -g and see if it identifies the point of failure. You can try -O1, which specifies a lower optimization level, to lessen code reordering and perhaps help you pinpoint where the error is.

[Christian_Ride]

Thanks. I tried -traceback without -g and it isolated where the error is occurring. I guess the older version (10.0.023) optimizes (or rearranges) the code differently from the latest version (XE 2011).

[mriedman]

This is an interesting statement. Until now I thought that -g does not disable optimizations as long as -O or -O3 is specified at the same time. At least this is what the users guide says. Could you please clarify ?

[TimP]

I suppose Steve didn't mean to confuse you on this question; it seems that he was answering a post where -g was in use without a -O option, and he suggested adding -O1.

[jimdempseyatthecove]

>>and it isolated where the error is occurring. I guess the older version (10.0.023) optimizes (or rearranges) the code differently from the latest version (XE 2011).

It is very likely that the error was occuring in the older code as well but did not express itself with crash or incorrect results. Getting good results by chance is not a proper way to program - sooner or later something will change and then you will be getting incorrect results or crash. The incorrect result are particulary bad considering that you may have run this program for years without having problems with the output. IOW your confidence in the output is based on faulty code (which just happened to produce good results to date). Some minor change in the input data or (as in this case) re-compiling with different version of compiler or different options now exposes the problem in the code.

Jim Dempsey

[Christian_Ride]

Good point. The code for this program that I'm running went through at least 30 different programmers with no real programming knowledge/experience--they are all scientists. I'd be the 31st person--also a scientist, not a computer programmer, to add new code and keep this thing running. However like those before me, our priority is to just get the calculations right. As long as the program output matches the calculations done by 5 mathematicians as a check, we will probably just leave it as it knowing the dangers of not properly coding this program. Someday there will be a funding agency that will provide the funding for us to hire somone to rewrite the program, but until that day...