1#IND in Floating Point Stack Register

[smedvedoff]

We are transitioning from CVF to IVF, building and running legacy code that worked fine under CVF. Under IVF, I'm getting NaN as the return value from an invocation of the intrinsic function MIN(). All passed parameters have good values. I looked at the disassembly of the code and found that after a FLD instruction, the stack top register ST0 had a value of 1#IND. Here are the assembly instructions down to the FLD that produces the 1#IND:

TTHIT = MIN(TPHSE,TPRNT,TRATE,TOPTM,TTAPE,TTHRST,TPLEV,TNEDS,TEVENT)
004B4B5F DD 05 98 C0 34 02 fld qword ptr ds:[234C098h]
004B4B65 DB 7D D0 fstp tbyte ptr [ebp-30h]
004B4B68 DD 05 A0 C0 34 02 fld qword ptr ds:[234C0A0h]
004B4B6E DB 7D DC fstp tbyte ptr [ebp-24h]
004B4B71 DD 05 90 C0 34 02 fld qword ptr ds:[234C090h]
004B4B77 DD 05 B0 C0 34 02 fld qword ptr ds:[234C0B0h]
004B4B7D DD 05 A8 C0 34 02 fld qword ptr ds:[234C0A8h]
004B4B83 DD 05 F0 C0 34 02 fld qword ptr ds:[234C0F0h]
004B4B89 DD 05 50 76 35 02 fld qword ptr ds:[2357650h]
004B4B8F DD 05 B8 8F 35 02 fld qword ptr ds:[2358FB8h]
004B4B95 DD 05 C0 92 35 02 fld qword ptr ds:[23592C0h]

Here is the value of address 23592C0 prior to the last FLD instruction being executed:

MEMORY CONTENTS

0x023592C0 ea 8c a0 39 59 3e 29 46 00 00 00 00...

Comparing to other known values, it appears that the address contains a valid 8-byte floating point value of 1.0e+30. I would think that the last FLD instruction would load this valid value into register ST0, however after it is executed, the registers contain the following:

EAX = 00002061 EBX = 00000000 ECX = 00000002 EDX = 00000001 ESI = 00000003 EDI = 00000004 EIP = 004B4B9B ESP = 0354FD68 EBP = 0354FDAC
EFL = 00000202

CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 003B GS = 0000

ST0 = 1#IND ST1 = +1.0000000000000000e+0030 ST2 = +1.0000000000000000e+0030 ST3 = +1.0000000000000000e+0030
ST4 = -6.0000000000000000e+0000 ST5 = +1.0000000000000000e+0030 ST6 = +1.1274999999999999e+0000 ST7 = +2.0909688918211653e+0007
CTRL = 027F STAT = 2A61 TAGS = 0800 EIP = 004B4B95 EDO = 023592C0

Prior to execution of the last FLD instruction, the registers contained:

EAX = 00002061 EBX = 00000000 ECX = 00000002 EDX = 00000001 ESI = 00000003 EDI = 00000004 EIP = 004B4B95 ESP = 0354FD68 EBP = 0354FDAC
EFL = 00000202

CS = 001B DS = 0023 ES = 0023 SS = 0023 FS = 003B GS = 0000

ST0 = +1.0000000000000000e+0030 ST1 = +1.0000000000000000e+0030 ST2 = +1.0000000000000000e+0030 ST3 = -6.0000000000000000e+0000
ST4 = +1.0000000000000000e+0030 ST5 = +1.1274999999999999e+0000 ST6 = +2.0909688918211653e+0007 ST7 = +2.0909688918211653e+0007
CTRL = 027F STAT = 3061 TAGS = 0000 EIP = 004B4B8F EDO = 02358FB8

So what I don't understand is how this assembly load instruction results in an indefinite value (or whatever 1#IND means) in the register. This seems to be an issue at the floating point processor level. Is there a project setting that could explain/correct this?

Thanks,

Steve

[Steven_L_Intel1]

Try turning on "Check Floating-Point Stack" under Fortran -> Floating Point. If an error is discovered, you'll get an access violation at that point.

Other things to try - turn on Generate Interface Blocks and Check Routine Interfaces, both under Diagnostics. Under Optimizations, select "Require Intel Processor Extensions" and choose the setting for your processor. (If you are not using an Intel processor, go to the Command Line page and type in for Additional Options, /QxW.) This will cause the compiler to use SSE registers rather than the floating point stack for most operations.

My guess is that you're corrupting the floating point stack somewhere. This can happen if you CALL a function or reference a subroutine as a function.

[smedvedoff]

Steve,

Yourhunch was correct. I turned on "Check floating-Point Stack" and found an instance of a function being CALLed. Correcting this error eliminated the problem. Many thanks for your suggestion.

As this is legacy code, I'm not sure why a similar problem wouldn't have occurred in CVF, unless it was masked by some project setting. I believe there was one related to "flawed processor".

Thanks again,

Steve

[Steven_L_Intel1]

Just luck, really. The same issue can appear using CVF. All it would take is a different sequence of instructions to trip over the problem.

In version 10, we've turned on interface generation/checking by default in newly created projects. It should help detect errors of this nature. Use of explicit interfaces, which I always recommend, would nip it in the bud.