topic Debugging with print statements changes results in Intel® Fortran Compiler

Debugging with print statements changes results

FortranUser22 — Wed, 25 Jan 2023 16:31:05 GMT

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.

Re: Debugging with print statements changes results

jimdempseyatthecove — Wed, 25 Jan 2023 17:17:01 GMT

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

Re: Debugging with print statements changes results

Steve_Lionel — Wed, 25 Jan 2023 20:56:49 GMT

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.)

Re: Debugging with print statements changes results

JohnNichols — Wed, 25 Jan 2023 22:20:29 GMT

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.

Re: Debugging with print statements changes results

Steve_Lionel — Thu, 26 Jan 2023 00:31:13 GMT

@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.

Re: Debugging with print statements changes results

FortranUser22 — Thu, 26 Jan 2023 05:40:38 GMT

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.

Re: Debugging with print statements changes results

FortranUser22 — Thu, 26 Jan 2023 06:08:09 GMT

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

Re: Debugging with print statements changes results

FortranUser22 — Thu, 26 Jan 2023 06:31:41 GMT

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.

Re: Debugging with print statements changes results

Steve_Lionel — Thu, 26 Jan 2023 14:23:25 GMT

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

Re: Debugging with print statements changes results

jimdempseyatthecove — Thu, 26 Jan 2023 14:35:15 GMT

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

Jim Dempsey

Re: Debugging with print statements changes results

FortranUser22 — Thu, 26 Jan 2023 19:25:22 GMT

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

Re: Debugging with print statements changes results

JohnNichols — Thu, 26 Jan 2023 20:32:32 GMT

! 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.

Re: Debugging with print statements changes results

JohnNichols — Thu, 26 Jan 2023 20:33:58 GMT

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

Re: Debugging with print statements changes results

JohnNichols — Thu, 26 Jan 2023 23:19:23 GMT

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.

Re: Debugging with print statements changes results

JohnNichols — Thu, 26 Jan 2023 23:21:28 GMT

the integer number according to EXCEL as a HEX is

FFCCCCCCCC

Re: Debugging with print statements changes results

Steve_Lionel — Fri, 27 Jan 2023 01:47:14 GMT

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.

Re: Debugging with print statements changes results

JohnNichols — Fri, 27 Jan 2023 16:14:52 GMT

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

Re: Debugging with print statements changes results

JohnNichols — Fri, 27 Jan 2023 16:21:55 GMT

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

Re: Debugging with print statements changes results

Steve_Lionel — Fri, 27 Jan 2023 17:39:55 GMT

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.

Re: Debugging with print statements changes results

JohnNichols — Fri, 27 Jan 2023 20:07:47 GMT

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.