a COMPLEX*16 problem in IVF 9.0

[jbalster]

Steve,

This one was a doosey to figure out. I have a routine that contains a COMPLEX expression who's real component is assigned to FVAL. The first time it's executed, it generates a NaN for a result. If you re-run the exact same expression, it generates a COMPLEX result as it should have in the first place. All other subsequent executions of the statement also generate a COMPLEX result. If I try to reproduce the problem in a smaller code block, it doesn't seem to generate the NaN. My work around was to paste in a 2nd copy of the assignment statement so it's calculated twice, the 2nd assignment statement yeilding a result. I'll try to include here all of the relevant information I can without including the entire routine. My source is F77 in a .FOR file and this is also a mixed language project with a C++ (.net 2003 version) main program and my command line compilation switches (custom build rule) are

/nologo /Zi /Od /include:"." /include:".." /include:"...." /f77rtl /intconstant /warn:ignore_loc /warn:truncated_source /Qsave /assume:dummy_aliases /Qzero /names:uppercase /iface:cref /module:"./" /object:"./" /traceback /check:none /libs:static /threads /dbglibs /c

IMPLICIT DOUBLE PRECISION (A-H,O-Z)

COMPLEX*16 Z

Z = (-0.681266158659309,0.000000000000000E+000)

N2 = 1

S = 1.0

THRESH2 = 11.5129251480103

SIGMA = 2.99365733225037

XNU = 0.0

FVAL=-DREAL(CDEXP(-CDLOG(Z)

* -N2*CDLOG(1.0+Z)-S*Z/(1.0+Z)

* +THRESH2*Z)*DCMPLX(1.0D0,SIGMA*XNU))/3.1415926536D0

When I duplicate the FVAL= statement, then it only generatesa NaN the very first time the statement is executed, and after the very first execution, it generates a result value instead of a NaN. I had one of our junior staff put this code into a separate file&project, but it did not reproduce the NaN then. This total project is over 1,000,000 lines of Fortran 77 plus over 100,000 lines of C++. Elsewhere in the code, the results generated from the RELEASE and from the DEBUG configurations were different from each other until I doubled up the FVAL= statement shown above. The actual statement I copied into this message was added in a one time executed IF()THEN block that is not executed a second time, with the local variable initializations shown above and the debugger shows it did generate a NaN when in the context of the larger routine and also in turn, solved the problem so that the results from both the DEBUG and RELEASE versions now match the results we got from CVF 6.1

[Steven_L_Intel1]

I'm sorry to hear that you had a problem, but I can't see that there's anything here that helps me investigate a possible compiler bug. The general symptom you describe is often caused by references to uninitialized variables - anything that changes the instruction stream can change the behavior.

If you'd like us to do something with this, please submit a test case to Intel Premier Support, and we'll be glad to investigate further.

[anthonyrichards]

I am not quite clear what the expression is that you are evaluating.

Are the asterisks at the beginning of each of the last two lines following 'FVAL='

continuation characters or multiplication symbols?

(I ask because you say the code is in a .FOR file, which implies fixed format, which means 72 characters maximum for code, which your statement exceeds)

Also, what value do you get? What is the 'correct' answer?

Message Edited by anthonyrichards on 07-20-2005 06:36 AM

Message Edited by anthonyrichards on 07-20-2005 07:50 AM

[durisinm]

You might try changing your statements to explicitly use double precision constants with your implicitly declared double precision variables. For example, S = 1.0D0 and (1.0D0 + Z).

Mike D.

[jbalster]

Sorry about not previewing the message before posting it. I forgot the blanks would get removed if it wasn't set as SRC

The last 2 lines were continuation lines with an * in column 6

Code:

      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      COMPLEX*16 Z
      Z = (-0.681266158659309,0.000000000000000E+000)
      N2 = 1
      S = 1.0
      THRESH2 = 11.5129251480103
      SIGMA = 2.99365733225037
      XNU = 0.0
      FVAL=-DREAL(CDEXP(-CDLOG(Z)
     * -N2*CDLOG(1.0+Z)-S*Z/(1.0+Z)
     * +THRESH2*Z)*DCMPLX(1.0D0,SIGMA*XNU))/3.1415926536D0

Well, I just completed a detailed debugging session and I found that if I stop at the beginning of the first occurance of this statement, then show the floating point registers and change the value of register TAGS from 0FFF to FFFF that the problem goes away and I get a result instead of a NaN. I discovered this by using the debugger to re-execute the statement and comparing the registers after each machine instruction in the disassembly between a run the first time thru the code vs. a subsequent run thru the same code. Now TAGS only needs to be set one time and once set, stays set.

[jbalster]

That last message of mine had a question sort of hidden at the end of it.

Icompleted anextensive debugging session where I ran 2 debuggers in parallel and compared them. Since this problem did not happen after the first time the FVAL= assignment statement was executed I tried comparing the first execution of the statement with a 2nd execution of the statement.

I was primarially looking at the registers and stepping thru the machine code disassembly

I found that the main difference at the beginning of the statement in question wasthat the value of the TAGS register was different.

I decided to try and change the value of register TAGS from 0FFF to FFFF prior to the first execution of the statement since the TAGS register had the value of FFFF on the subsequent executions of that statement which worked. I found that by changing TAGS to FFFF that the problem goes away and the first execution of the statement also yeildsa result instead of a NaN.

[anthonyrichards]

You have lost me. What is 'TAGS'? Where is it? Why are you allowed to change it? You have still not posted what the 'correct' answer should be.

Where is the Nan?

Have you tried splitting your FVAL function evaluation into parts i.e.

parta=

partb=

partc=

partd=

FVAL = (parta+part+partc)/partd

or whatever, and seeing where it turns up?

[jim_dempsey]

A few simple things to try.

Try initializing your double precisionvariables with double precision constants. Example:

Z = (-0.681266158659309D0,0.000000000000000D0)

The same for the others. There may be a problem an assumption of the state of the FPU when a variable is initialized with a value that is not in the precision of the variable. It is a simple enough test.

Likewise use double literals on expressions. Also consider using a DOUBLE for N2 (or eliminate it due to it being 1)

IMPLICIT DOUBLE PRECISION (A-H,O-Z)

COMPLEX*16 Z

Z = (-0.681266158659309D0,0.000000000000000D0)

wasN2 = 1.0D0

S = 1.0D0

THRESH2 = 11.5129251480103D0

SIGMA = 2.99365733225037D0

XNU = 0.0D0

FVAL=-DREAL(CDEXP(-CDLOG(Z)

* -wasN2*CDLOG(1.0D0+Z)-S*Z/(1.0D0+Z)

* +THRESH2*Z)*DCMPLX(1.0D0,SIGMA*XNU))/3.1415926536D0

If you need further assistance let me know.

Note, I had similar problems in conversion of an F77 project (715 files/6MB code). Drove me nuts for a while. Things worked in Debug configuration and broke in Release configuration.

I did not figure out the real cause. My guess though is that a REAL*4 got pushed on the stack and was later assumed to be the alternate higher precision.

Much of the problems (but not all) were corrected by specifying the default real precison to that desired, in my case this was REAL*8.

In your case you may have to explicitly specify precisions.

Good luck with your conversion project.

Jim Dempsey