Debugging with print statements changes results

[FortranUser22]

Hello,

My results change when I use print statements to debug the code. Is this problem related specifically to the variable I m printing or it can be any other variable that was not initialized. All variables appear to be initialized.

I have consulted a similar question on this forum: Adding debugging 'print' statements changes variable values - Intel Communities and I could not post in the same thread.

 I m using intel fortran with visual studio. Is there any option that I can change on the project options that can help me resolve the problem and identify the problem.

Thank you for your help.

[jimdempseyatthecove]

What are your compiler options (with and without your debugging print statements)?

Have you recently performed a Debug Build (/Od) with full runtime diagnostics (/warn:all)?

Inserting print statements or call to external procedure in a program that is optimized can cause code generation differences the storage/use of intermediary values being stored in registers or written to program variables. While the results should be the same, the differences can expose a compiler optimization issue.

*** Note, floating point numbers are approximate numbers, the code path to produce a result taking path A may differ slightly from path B. These two results are approximately the same as they may differ in the accumulation of roundoff errors within each path.

Jim Dempsey

[FortranUser22]

I m using now  (/Od) with runtime error checking : - check all

[FortranUser22]

Where can I select  (/warn:all) at the full runtime diagnostics? When I go to project properties->config properties->Fortran->Run-time->Runtime Error Checking-> custom or all (check all). I could not find where to select warn all.

[Steve_Lionel · Accepted solution]

In my experience, this symptom is almost always due to uninitialized variables or code elsewhere in the program that corrupts data (writes outside bounds, etc.)

[JohnNichols]

The uninitialized variables are initialized to really weird numbers, but Steve is right, it can be a headache and one worth fixing. You should turn on the warnings.  Also things like implicit none being left out can be a pain.  

[Steve_Lionel]

---

@JohnNichols wrote:

The uninitialized variables are initialized to really weird numbers, 

---

No, they are uninitialized - you get whatever random value was in memory at the time, which may not be the same run to run.

[JohnNichols]

!  Console3.f90 
!
!  FUNCTIONS:
!  Console3 - Entry point of console application.
!

!****************************************************************************
!
!  PROGRAM: Console3
!
!  PURPOSE:  Entry point for the console application.
!
!****************************************************************************

    program Console3

    !implicit none
    
    integer i(100)
    real k(100)
    integer kp
    integer kt

    ! Variables
    print *,kp,kt,p,p1
    p = 1
    ! Body of Console3
    print *, 'Hello World'

    end program Console3

Using a stock standard sample program and first running with implicit none you get 

Integers are always cast to this number, which if is hexadecimal 33333334 if I drop the -, my calculator does not handle minus

the i array is set to 0 and the k array is set to 0

The reals are set to -1.07 etc...  Which as a best guess related somehow to the integer number, and some one will correct me if I am wrong.  

Implicit none has no effect, I did not turn warn of un-initialized etc...

There is no random garbage, there is garbage from the compiler writer, but at least for arrays it is zero, it would be nice if the kp,kt and p,p1 were zero, but that is to much to ask. 

[JohnNichols]

I have pointed out this number before and I think Jim has stated the hex number. 

[JohnNichols]

program Console3

    !implicit none
    
    integer i(100)
    real k(100)
    integer kp
    integer kt
    real p 
    real p1
    
    kp = kt/100000
    p = p1 /1000000.0
    ! Variables
    
    print *,kp,kt,p,p1
    p = 1
    ! Body of Console3
    print *, 'Hello World'

    end program Console3

I can use the variables in formula and the results are as expected.  Can we ask the compiler writer when they set the value, it is after the real is declared, but before the math or print.  

[JohnNichols]

the integer number according to EXCEL as a HEX is 

FFCCCCCCCC

[FortranUser22]

Many thanks for your reply. I m working to identify the issue. The option check all for runtime pointed me to a variable that was defined in an "if statement" but that was not an  issue.

The code has 4 nested loop with some two dimesional matrices calculated as summations. I have verified that all sums are initialized as 0 before the start of the specific loops.

Thank you again.  

[Steve_Lionel]

Click on the down arrow to the right of the current option value and you'll get the choice of all. For example:

[FortranUser22]

-warn all catches many variables that are not initialized but not all. In particular, vectors or matrices where only part of the elements are initialized but not all. 

I went to Fortran->data and then initialized variables to Nan to find all variables that are not initialized. Is this a good strategy in your opinion?

[jimdempseyatthecove]

FYI warn:all is compile time diagnostic, check:all is runtime diagnostic.

Jim Dempsey

[FortranUser22]

Many thanks for your replies and clarification. I m working on debugging the code... 

[Steve_Lionel]

In a debug configuration, some memory gets allocated with the hex value CCCCCCCC. That doesn't help when stack contents are reused, and doesn't apply to a release configuration.

[JohnNichols]

In release mode all variables are set to zero in this sample.  

[JohnNichols]

The final question is why the difference between debug and release mode?  

[Steve_Lionel]

You can't make assumptions based on simple test programs. Over the years I've seen MANY complaints from users that variables weren't initialized to zero, because in some past build they seemed to be. Intel Fortran DOES have an option to do this, off by default, and you should not use it. Variables that are statically allocated will tend to be zero, but that's not something to rely on. With full Fortran 2018 semantics enabled all procedures are recursive by default, so variables not marked SAVE will not be static. (This is not the default in the current version - you must specify /standard-semantics.)

Debug versus Release changes a LOT of things about code, and variables will be more likely to live in registers or on the stack. Also debug configurations link to the debug C++ library which sets allocated data to CCCCCCCC.

[JohnNichols]

Ok.  Taking long assumptions from short data is fraught with error.  One of the things I learnt in LISP Programming is 

(setq a 1) is really useful.