Thread: Odd release build behavior in MSVC 2005

The following lines of code do not produce the correct values in release builds in MSVC 2005. Note that m_rect is a RECT and its members have been set to zero prior to this. Vector3 is a struct with 3 floats x,y and z. These lines do work in debug builds.

Code:

    Vector3 pos = m_pFrame->GetPosition();
    Vector3 scale = m_pFrame->GetScale();
    
    m_rect.left = static_cast<LONG>(pos.x - (scale.x * 0.5f));
    m_rect.right = m_rect.left + static_cast<LONG>(scale.x);
    m_rect.top = static_cast<LONG>(pos.y - (scale.y * 0.5f));
    m_rect.bottom = m_rect.top + static_cast<LONG>(scale.y);

These lines work in release builds and debug builds.

Code:

    
    Vector3 pos = m_pFrame->GetPosition();
    Vector3 scale = m_pFrame->GetScale();
    
    float scaleX2 = scale.x * 0.5f;
    float scaleY2 = scale.y * 0.5f;
    float left = pos.x - scaleX2;
    float top = pos.y - scaleY2;
    float right = left + scale.x;
    float bottom = top + scale.y;
    m_rect.left = static_cast<LONG>(left);
    m_rect.right = static_cast<LONG>(right);
    m_rect.top = static_cast<LONG>(top);
    m_rect.bottom = static_cast<LONG>(bottom);

Why does the first example only work in debug builds and not release builds? Are they not syntactically the same lines of code? Is my FPU possibly in a bad state prior to executing these lines and somehow debug is resetting the state so they work or is it something else?

Here is an example output in release using the first block of code:

Cell rectangle: PosX: 75.000000 - PosY: 487.500000 - ScaleX: 100.000000 - ScaleY: 15.000000, Top: -1012 - Left: 74 - Right: 124 - Bottom: -997

Here is an example output in release using the second block of code:

Cell rectangle: PosX: 75.000000 - PosY: 487.500000 - ScaleX: 100.000000 - ScaleY: 15.000000, Top: 480 - Left: 25 - Right: 125 - Bottom: 495

Any ideas?

Where's the printing code? If it's the very next line after these pieces, then the compiler is dodgy. If it's later on, set a data breakpoint and see who or what is overwriting the values.

The printing code is immediately after the calculations. I removed all code between the calculations and the printing just to be sure no other methods were messing the values up or somehow hosing the memory. I think the compiler is at fault here. I have sent this code to some co-workers and talked with them as well and they also cannot see why the first block of code would not work in release.

O_o

Have you already yanked that code from its home and tried it?

Soma

No I have not tried the code by itself. My guess is it would probably work. Perhaps the FPU is in a bad state prior to executing the code in my function.

If some other code is trashing m_pFrame, it may cause members of pos and scale to have different values ..... which would mess up your calculations and output.

Although m_pFrame is a pointer the only object with access to it is the object using it. It is created by the object, used by the object, and not exposed outside of the object. I checked the code in m_pFrame for position and scale and they are D3DXVECTOR3 structures and are on the stack inside of the frame class.

m_pFrame is valid and all its members are correct as well as the values of pos.x, pos.y, pos.z and scale.x, scale.y, and scale.z as verified by printing the values out. After changing the code to match the second block the program runs fine and everything 'appears' to work. Perhaps there is something else wrong prior to this and this little section of code is leading me off into the weeds. I am definitely not opposed to the idea that something else in the code is amiss which is causing this behavior. This was my first suspicion and usually is when I get weird or unexpected behavior such as this.

Firstly, the second code is not quite equivalent to the first in the calculations of m_rect.right and m_rect.bottom (conversions of float <-> LONG occur in different sequence).

Yes this is correct. However would that not mean that at least m_rect.left and m_rect.top would be correct and m_rect.right and m_rect.bottom would be incorrect? Since they are all incorrect I doubt this is the issue.

I will look into the code some more to see if I can find anything that occurs before this that could possibly cause undefined behavior to occur. Somehow I don't think this is going to be simple to find.

Originally Posted by brewbuck

There are known bugs in 2005 floating point optimizer. If you add "/fp:strict" to switches, does it work?

Hmmm. Good information. I will try that and let you know the results.