Issue with REAL*4 array value re-initialize to 1.8367099E-39

[Narenu]

I don't have much experience with FORTRAN. I've been assigned to work on legacy FORTRAN application. I have upgraded our legacy solution from "Intel Fortran Compiler for IA-32 applications, Version 10.1.030" to"Intel Composer XE 2013 SP1 Update 4 for Windows". I can build and run the application from VS2013. But I've noticed some strange behaviors,

1. I've a REAL* array (common block), initialized with all zeros. But when I debug through the code, the array values changed from 0 to 1.8367099E-39 when it is used in one subroutine. Somehow the array lost it original values.When I run the same code in older version, it keeps the values to 0. Does anyone know why the value changed to 1.8367099E-39?

Here are my project properties from command line:

VS2013 Fortran Properties:
/nologo /debug:full /Od /I"INC" /reentrancy:none /Qcoarray:shared /Qopenmp-report1 /Qpar-report1 /Qvec-report1 /Qdiag-disable:8291,8577,8290 /integer_size:16 /Qauto /align:rec4byte /align:commons /fpconstant /iface:cvf /module:"..\..\Objs\Debug\ArEngine\\" /object:"..\..\Objs\Debug\ArEngine\\" /Fd"..\..\Objs\Debug\ArEngine\vc120.pdb" /check:pointer /check:uninit /libs:static /threads /dbglibs /winapp /4Yportlib /c

VS2008 Fortran Properties:
/nologo /Zi /Od /include:"INC" /integer_size:16 /Qauto /align:rec4byte /align:commons /Op /fpconstant /iface:cvf /module:"..\..\Objs\Debug\ArEngine\\" /object:"..\..\Objs\Debug\ArEngine\\" /libs:static /threads /dbglibs /winapp /4Yportlib /c

[mecej4]

There are any number of reasons why things happen, and it is not useful to speculate. Usually, such problems are caused by assuming that the non-standard but default behavior of one compiler (the old one) is going to be the same in the new compiler.

Please post actual code so that someone else can reproduce the problem and suggest a solution.

[TimP]

The quoted symptoms could be due to improper sharing with integer data for example missing initialization. Option Qzero may be capable of 'interim fix up.

[Narenu]

mecej4 wrote:

There are any number of reasons why things happen, and it is not useful to speculate. Usually, such problems are caused by assuming that the non-standard but default behavior of one compiler (the old one) is going to be the same in the new compiler.

Please post actual code so that someone else can reproduce the problem and suggest a solution.

Not sure if this will help, but I am posting some extract from the code that creates issue. One more thing to note is we don't explicitly initialize the array values to zero. This variable is defined in two include files. 

Include file: VERSION.INC

REAL*4    
SVOL COMMON/VERSION/ SVOL(18) 

Include file: VERSION1.INC 

REAL*4    
SVOL COMMON/VERSION/ SVOL(18) 

Somehow it knows initially the values are zero. It goes through multiple subroutines before it goes to PMONTH. The value here is SVOL(1)    0.0000000E+00    REAL(4)  

Fortran File: VERS.FOR 

SUBROUTINE PMONTH()  --> When it comes to this subroutine, the value changes to SVOL(1)    1.8367099E-39    REAL(4)  
INCLUDE "VERSION.INC"   
--it does something here 

END

[Narenu]

Tim Prince wrote:

The quoted symptoms could be due to improper sharing with integer data for example missing initialization. Option Qzero may be capable of 'interim fix up.

Thanks for your suggestion, I tried with Qzero, but still it does the same. I've also tried Qsave but that didn't help. I am trying to fix this by not making changes to the code, because it is a legacy product, and don't know what else will fail.

[FortranFan]

Narenu wrote:

I don't have much experience with FORTRAN.  . .. . Somehow the array lost it original values.When I run the same code in older version, it keeps the values to 0. Does anyone know why the value changed to 1.8367099E-39?

..

What you're facing could be symptoms of a larger issue with how you're setting up and building your application in Visual Studio.  As mecej4 indicated, can you post on this forum a zip of all files including the source code and Visual Studio project and solution files of a reproducer example?  If not, do you have the option to contact Intel Premier Support?

[mecej4]

Your application may be "legacy", but the two compilers that you listed (10.1 and 2013 SP1) do not differ in how they treat local variables and in calling conventions, at least for old F77 code.

We don't explicitly initialize the array values to zero.

If you reference those array elements (e.g., by using them in an expression on the right side of an assignment, in an output list, subroutine argument list, etc.) the program does not conform to the language rules and the behavior is "undefined".

If those variables are defined (by assignment statements, in an input statement or by passing the variable as an argument to a subprogram in which it gets defined), things should be OK, but you may have to track down the location where the variables get defined.

If the value that you reported (1.8367099E-39) is that of a 32-bit real,note that it could indicate memory being handled incorrectly. That number is smaller than the smallest normalized IEEE 32-bit number, and has a rather odd (in fact, too even) internal representation: Z'00140000'

[andrew_4619]

Just watch a variable of interest in the debugger and using breakpoints and stepping through the program line by line .find the actual point that it changes, that should give you a bug clue. At the moment it is all guesswork..

[jimdempseyatthecove]

What you may have, is an earlier COMMON in memory that is being indexed out of range, or a mis-match of COMMON declarations. First search for all instances of your common, and verify that the array SVOL is indeed REAL*4.

Also note, really old Fortran programs had issues with character variables, and it was not uncommon to read ASCII text into the reals, then elsewhere, threat the variable a character (implicit UNION by way of different COMMON declarations or by assignment).

Jim Dempsey

[Narenu]

Thank you all for your suggestions. I was able to identify the issue. 

I find out where we initialize that REAL variable. If I initialize with 0, it changes the value to 1.8367099E-39. But if I initialize with 0.0, it initializes correctly. Looks like something changed in the new compiler is causing this behavior. Will let you all know if I find out what change is causing this issue.

[jimdempseyatthecove]

This may be symptomatic of a different problem.

What is the value of the real variable prior to, but at the statement that performs the initialization?

(place break point on initialization statement and look)

Then step past the statement and look again

If the initialization shows 0.0 following the initialization statement, but shows non-zero in the subroutine/function where the problem was observed, then while at the line after the initialization, use the debugger to set a data change break point. Usually there is no shortcut icon to do this, instead, click on Debug | New Break Point | New Data Break Point.

If the debugger complains about the symbol, then open a memory window, enter the symbol variable, and this will show you the hex address of the variable with data. Select, copy the address of the variable, then go back to the  Debug | New Break Point | New Data Break Point and enter the address (paste). Note you may have to remove the leading "0x" and suffix the number with "h" (a quirk of the debugger). Check C/C++ address, byte count of 4. Then resume the program. It should break when the data changes.

If the break does NOT occur, and when you reach the subroutine where you saw the initialization error (assuming you left a break point there) then use the memory window, type in the symbol name again, and compare the address as known in the subroutine with the problem against the address in the initialization routine. If the addresses differ, then this indicates your namd common blocks are different.

Jim Dempsey