Floating point stack overflow

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.


Answer this question

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

    Hi Mark,
      We can't see your attached document there. Could you please make sure to attach it.

    Thanks,
      Ayman Shoukry
      VC++ Team

  • Jmp

    Thanks Mark,
      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

    I hope you will consider a hot fix for this bug, and not wait for a service pack in the middle of 2006.  Of course, I had no trouble working around this particular instance of the bug.  What I'm worried about is the next time it happens.

    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

    Sorry, I have now attached it.  The first time, I clicked browse and selected my file, but it wasn't obvious to me that I also had to click "Add Attachement" over on the other side of the text field.

    Mark


  • Coyote13

    The compiuler BE folks have taken a deeper look and posted a reply at:

    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

    I agree. Please add such comments to the bug link.

    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
    00073 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
    0007f 5f pop edi
    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



  • Floating point stack overflow