My application works fine in VS2003, but in VS2005, it is producing an overflow of the floating point stack. This seems like it must be a code generation error in the new compiler. Has anyone else experienced this problem
In the particular case I am looking at, I step through the instruction FLDZ in the disassembly window. Instead of getting a zero in ST(0), I get 1#IND, and the SF and C1 bits are set in the x87 FPU Status Word. The first time through this code it works OK, but this second time through, the FPU tags register shows that the stack is full before the FLDZ instruction.

Floating point stack overflow
Jimmy_Sanu
Bug is fixed in VS2005 SP1. You can download beta of SP1 from http://connect.microsoft.com/visualstudio. Hopefully, SP1 will be officially released early next year.
Eugene
Darren_Melb_Aust
My program gets random crashes because of floating point starck overflow. I got NET2005 SP1 Beta. BUt I still have the same problem. Can you share the test program I want to know whether my problem is same as the one and whether the one is fixed in SP1.
Thanks,
Yawei.
Rich1212
Mark,
They are just double. Yes, I should use %f.
The problem is only shown in ther release build. I built my release project with debug information. The debugger showed -1.#IND00. However, I did not trust the debugger value. So I used OutputDebugString to print out the values in output window. I have disabled the optimization. It did not help either.
I hope somebody from MS can give us some explanations.
Thanks,
Yawei.
Scott Steigerwald
We can't see your attached document there. Could you please make sure to attach it.
Thanks,
Ayman Shoukry
VC++ Team
Jmp
Please keep an eye on the link you provided. The responsbile folks will take a look soon and update the link with any feedback.
Thanks for taking the time to report the issue!
Thanks,
Ayman Shoukry
VC++ Team
Manu_ivanohe
Hi Yawei,
Doesn't look like the same problem to me.
Are DOUBLE, nvec3 and rot defined to be long double If not, you don't want %lf in your Format strings, you just want %f. (The 'f' is for "fixed precision" not for "float".)
Do you know rot[0][2] is -1.#IND00 by looking at it in the debugger Is the code optimized Sometimes things look funny in the debugger.
Mark
Chris Stewart - WUK
When the floating point stack starts to fill up, no problem is created until much later in the program when the stack finally overflows, and even then the program keeps running - it just gets incorrect results from its floating point calculations.
Tracking the problem back to the point where items were left on the stack can take many hours of tedious stepping through the debugger, watching the floating point stack tag bits and examining the disassembly window to see if the bits are right or wrong.
Filiberto Selvas MSFT
Mark
Coyote13
http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx feedbackid=6cc696cc-89b3-4bd8-b81d-8a9b8053b04e
Here is a copy of the reply:
Thanks for reporting this issue. This is a bug in the floating-point stack mapping code (turns virtual FP registers to actual FP stack locations) and there is no easy workaround. We will probably try to get this bug fixed for our next release or update of VC 2005 . In the meantime you could: disable optimizations in this function, or remove the last "if" statement in the function since function will return false anyway.
Thanks again,
Marko Radmilac
VC++ BE Team
Mark, please let me know if you have any difficulty in using the workarounds supplied. I will be more than happy to work with you on that.
Thanks,
Ayman Shoukry
VC++ Team
Rover
That document on the floating point model is excellent. Thanks. It turns out my problem is a code generation bug in VS2005, and I have simplified it and submitted it. Here is the bug report
http://tinyurl.com/7z3cy
mmickas
Once more, thanks a lot Mark for raising the issue. Also, mention that you want a hot fix for it.
Thanks,
Ayman Shoukry
VC++ Team
Vladimir Bychkov
Hi Yawei,
The MS bug report (http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx FeedbackID=100061) is marked fixed on 3/10/2006, but my compiler (version 8.0.50727.42 (RTM.050727-4200), running on x64) still spits out the bad code and doesn't find any updates online.
The sample follows. Compile it with:
cl /O2 /FAcs /c pmtest.cpp
At the end of the generated .cod, you will see this code that neglects to pop the return value of GetDeflectionFactor:
00071 8b cf mov ecx, edi
0007f 5f pop edi00073 e8 00 00 00 00 call GetDeflectionFactor@PmTool@@QBENXZ ; PmTool::GetDeflectionFactor
00078 8b ce mov ecx, esi
0007a e8 00 00 00 00 call GetDeflectionFactor@PmTool@@QBENXZ ; PmTool::GetDeflectionFactor
00080 32 c0 xor al, al
00082 5e pop esi
00083 83 c4 08 add esp, 8
00086 c3 ret 0 class PmTool
{
public:
int m_type;
double m_diameter;
double m_deflection_factor;
void CalcDeflectionAndStressFactors() const;
double GetDeflectionFactor() const
{
if (m_deflection_factor == 0.0)
CalcDeflectionAndStressFactors();
return m_deflection_factor;
}
static bool ToolSetOrder(const PmTool * t1, const PmTool * t2);
};
bool PmTool::ToolSetOrder(const PmTool * t1, const PmTool * t2)
{
if (!t1 && t2)
return true;
if (!t2)
return false;
if (t1->m_type == 1 && t2->m_type != 1)
return true;
if (t1->m_type != 1 && t2->m_type == 1)
return false;
if (t1->m_diameter > t2->m_diameter)
return true;
if (t1->m_diameter < t2->m_diameter)
return false;
if (t1->GetDeflectionFactor() < t2->GetDeflectionFactor())
return true;
if (t1->GetDeflectionFactor() > t2->GetDeflectionFactor())
return false;
return false;
}
Can someone from MS explain what happened to the fix Was it not really a fix, or has it not been released yet
Thanks,
Mark Gilbert
JasonDWilson
Let me put some of my codes here to describe the problem:
DOUBLE tempAngle = 0;
DOUBLE one_minus_cosine, cosine, sine ;
sine = sin( tempAngle ) ;
cosine = cos( tempAngle );
one_minus_cosine = 1.0 - cosine;
rot[0][0] = one_minus_cosine * nvec3[0] * nvec3[0] + cosine;
rot[1][1] = one_minus_cosine * nvec3[1] * nvec3[1] + cosine;
rot[2][2] = one_minus_cosine * nvec3[2] * nvec3[2] + cosine;
DOUBLE t1, t2 ;
t1 = nvec3[0] * nvec3[1] * one_minus_cosine;
t2 = nvec3[2] * sine;
csData.Format(
"nvec3 = %lf, %lf, %lf\n",nvec3[0],nvec3[1],nvec3[2]);OutputDebugString(csData); // will print out ->>>>>>>> nvec3 = 0.000000, 0.000000, 0.000000
csData.Format("t1 t2, one_minus_cosine, sine = %lf, %lf, %lf, %lf\n",t1, t2,one_minus_cosine, sine );
OutputDebugString(csData); //will print out ->>>>>>>>> t1 t2, one_minus_cosine, sine = 0.000000, 0.000000, 0.000000, 0.000000
rot[0][1]=t1+t2;
rot[1][0]=t1-t2;
t1 = nvec3[0] * nvec3[2] * one_minus_cosine;
t2 = nvec3[1] * sine;
rot[0][2] = t1-t2;
After the call rot[0][2] becomes -1.#IND00, Why does it become -1.#IND00
If I add a line of OutputDebugString(csData) before rot[0][2] = t1-t2, Then rot[0][2] becomes 0.000000.
Both NET2005 and NET2005 SP1 Beta have the same problems. I have tried to set different options, /fp:strict, /fp:fast, and /fp:precise,
It did not work.
I do not know whehter this is the same problem described in this thread. If so, should it be fixed in NET2005 SP1 Beta
Can somebody give me more information
Thanks.
Yawei.
cYruZ
We have made a total redesign of the floating point model in VC8.0. Take a look at http://msdn.microsoft.com/library/default.asp url=/library/en-us/dv_vstechart/html/floapoint.asp for a description of the new model. That might explain the different behavior. If you still think that this might be a bug in the VC8.0 compiler then please feel free to log the issue at http://lab.msdn.microsoft.com/productfeedback/default.aspx with a sample reproducing the bug.
Thanks,
Ayman Shoukry
VC++ Team