Different results in release mode and debug mode

[turkeydodo]

I have a set of FORTRAN codes and I got different results from release mode and debug mode.

I am using the IVF version:
 

Intel® Visual Fortran Compiler Integration for Microsoft Visual Studio* 2008, 11.1.3471.2008, Copyright (C) 2002-2010 Intel Corporation

I found that the reason is

Local variables forget to be initialized in my code

In release mode, these variables are forced to be 0 while in debug mode, these variable still keep the values in last call.

I am using the default compiling options from IVF and shows below.

Release mode: /nologo /module:"Release\\\\" /object:"Release\\\\" /libs:static /threads /c

Debug mode: /nologo /debug:full /Od /gen-interfaces /warn:declarations /warn:interfaces /module:"Debug\\\\" /object:"Debug\\\\" /traceback /check:bounds /libs:static /threads /dbglibs /c

I want to say this is abnormal for IVF. At least IVF should give me a warning message like "the variable is used before initialization" which is the usual check in language C or in old Compaq Visual Fortran.

I cannot even find this kind of warning check in compiling options. I only find an option for "Initalize local Saved Scalars to Zero" /Qzero. But I found this by taking me about half day to print variables and trace variables.

I guess this issue will bring lots of inconvinience and is a trap when people want to re-pick up their old fortran code.

So I strongly suggest IVF list this /Qzero to be an default compiling options for debug mode. Or IVF should add the warning check for variables used before initialization

IF IVF IS REALLY CARE ABOUT CUSTOMERS!!!

[TimP]

The defaults in Visual Studio project conversion set the CVF compatibility options to which you allude. Those can't be depended on, particularly if you start modernizing your code.   If you are interested in moving forward, it's important to correct any deficiencies which make your application non-compliant with Fortran standards.  /check option includes /check:uninit as a default, and there is a CVF compatible spelling option /CU.  There is also /Qtrapuv.  Other ways such as Inspector may be useful to catch unitialized variables which may still be a problem if you have added parallelization.

[turkeydodo]

I want to add it for this issue

In debug mode, after I add two options /Qsave and /Qzero, I got exact same results compare to those in release mode.

I also find similar post 

http://redfort-software.intel.com/en-us/forums/showthread.php?t=100440

It is headache for me (but also for most customers) to play so many compiling options. I don't know the focus of IVF. The focus is to make user more simple and easy to use it OR focus on complicated Fortran standards. More and more customer will escape if IVF makes things more complicated. I strongly suggest to tune the default compiling options to satisfy previous CVF options. This is a backward compatiblity issue. 
 

[Steven_L_Intel1]

I would very much disagree about /Qzero being the default.  We have had many customers thank us for revealing coding errors in their applications that CVF and other compilers did not.  However, the default for CVF converted projects is /Qsave, which will largely have the same effect.  CVF did not zero-initialize variables.

We do have /check:uninit as a default, but it doesn't catch everything.

[bmchenry]

As a suggestion (that will probably get shot down) perhaps you ight consider having a way to transfer all 'non debug' options from the debug tab to the release tab.
That might be a way to avoid many if not most of the 'different results' issues.
To compare options i find that by opening 2 separate sessions, one in debug and one in release, I then can modify the release options to be the same as debug (except of course the debug options).
And then close debug first! and then when you save the release option session they options are the same as debug.

I frequently we see folks who raise the 'different results' issue between debug & release and i believe it is mainly due to 'different options' set because they mess around with the options in debug and then don't make the same changes to release.

Ok, fire away! ;-)

[turkeydodo]

The problem is current default compiling option for debug did not tell me any coding error (succeffully compile and link) and the worse than that is it gives me wrong results.

I am not arging on any specific option like /Qsave or /Qzero to be added to default option. 

As a user, I want to use it more simple and easy. Either IVF told me where is the error in my code if my code is wrong; or IVF give me correct results if it does not say any wrong on my code.

The worst thing is IVF did not say anything wrong and give the wrong results!

User must check the complicated compiling option to figure out the reason! 

[Steven_L_Intel1]

I agree with you that the compiler should be able to diagnose uninitialized variables better. It remains something we're interested in.  If you had Intel Fortran Studio and used the Static Analysis feature, it would probably have detected this.

However, there are many coding errors the compiler cannot reliably detect.  It is not that the user must check the options, it's that the user should write correct code.  Uninitialized variables, or assuming SAVE semantics where the language does not specify it, is a coding error. That some other compiler hid the error from you doesn't make it any less of a coding error.

[Andac_L_]

I have a similar problem. I compared each options in release mode and debug mode. And when I am using Debug Multithreaded (/libs:static /threads /dbglibs) as Runtime Library in Debug mode I get wrong answers. When I change this option to Multithreaded, then I get correct results. Do you have an idea why I have an issue like this?

[mecej4]

The similarity that you mention is likely to be rather vague, as in "all buggy programs are similar". Noting this kind of similarity is worth next to nothing as far as locating and rectifying the problem is concerned.

You could have code that causes array bounds to be exceeded, code containing mismatched subprogram arguments, and uninitialized variables. Finding and fixing such errors is time consuming, but there are some compiler options to help you with the task, some of which have been mentioned in this thread.