I'm doing some tests with AngelScript and MSVC8, and I'm also running into problems with the unit tests in release mode.

More specifically the tests TestExecute32MixedArgs and TestExecuteThis32MixedArgs. In both of these cases the tests report that arguments 14,15,16 are wrong.

However, after some tests I have been able to confirm that this is not a problem with AngelScript, but more with the MSVC optimizer.

Debugging the code I can see that the arguments are indeed correct. The problem occurs when the arguments are loaded into the floating point register. Although the disassembly window shows me that the code was correctly generated by MSVC compiler the value loaded from the stack into the floating point register is incorrect. The following instruction is executed:

fld         dword ptr [esp+48h]

Where esp+48h points to the 14th parameter on the stack. The value on the stack at this location is 14.0f. But what is loaded into the st0 register is actually 1#IND. This is what I cannot understand.

It actually seems to fail due to what is already loaded into the other floating point registers, because if I move the unit test to the beginning of the main() function it doesn't fail. The code is exactly the same, only the contents of the floating point registers are different.

The same test work if I compile it without optimization for speed, using the exact same AngelScript library as before.

I'll try to figure out what is going on. But at least I know the problem is not with AngelScript.

[Edited by - WitchLord on February 3, 2006 9:18:15 PM]

I found the problem. [grin] And I'm very pleased to say that it was neither a problem with the AngelScript library, nor with MSVC8's compiler.

The problem wasn't even related to the TestExecute32MixedArgs test case, even though it was in that test the problem was detected. No, the problem was actually in the Test_Object3 test case.

What was happening is that an assignment operator was registered with AngelScript the following way:

float __cdecl AssignFloat2Float(float a,cFloat &b){	b=a;	return b;}

pSE->RegisterObjectType("Float", sizeof(cFloat), asOBJ_CLASS);if(pSE->RegisterObjectBehaviour("Float",asBEHAVE_ASSIGNMENT,"Float& f(float )",asFUNCTION(AssignFloat2Float),asCALL_CDECL_OBJLAST))		return false;

Can you spot the error? cFloat is a class with a single float member.

The problem is that when registering the assignment behaviour AngelScript is told that it is returning a reference to a cFloat class, but in reality it is returning a float by value.

While this didn't cause a problem in this test case, each assignment that the script made, left a float value in the float registers that were never removed again. In TestExecute32MixedArgs the MSVC8 compiler optimized the code so that all eight float registers are filled with values. The problem was that a couple of the registers were already occupied. The CPU (a P3 Celeron, in my case) was actually telling me this right from the start by setting the values to 1#IND instead of the real values, I just didn't understand that.

I'll finally be able to leave this problem and move on to more important matters. *phew*

I've had problems with the optimizer in MSVC6 before. To fix those problems I had to change the C++ code slightly. Mainly it had to do with the ++ operators, that may not be evaluated in the same order when optimized.

Maybe if you could show where you're having problems with different results, then I could help you figure out how to fix them.

Ah, thanks for figuring out how to reproduce the problems.

The first problem, with the declaration with initialization, looks like the problem that villemon had here. Maybe the fix that I provided for him will work for you as well.

The second problem, also sounds familiar to me.

Anyway, I'll verify both of these and add them to the regression tests so that I do not break them again in the future.

Regards,
Andreas

Pratty,

I've not been able to reproduce these last problems you noticed.

The bug with the double value only happens if the variable is declared with const, without const the variable is correctly initialized. Are you sure you were not testing with const?

The comparison of boolean values also seems to work just fine for me. Would it be possible for you to send me a small test case that reproduces the bug?