wrong order of elements in QList

[qtbeginner0]

What do you think "optimized out" means?

"optimized out" means to me, that this variable is not available anymore.
But to get the value of the variable the value has to be stored in memory somewhere.
I would like to see this part of memory.
Is it possible to view the memory of addresses like %st(0) and 0x68(%esp) ?

[wysota]

"optimized out" means to me, that this variable is not available anymore.
But to get the value of the variable the value has to be stored in memory somewhere.

No, it doesn't have to be stored in memory. If it was "optimized out" then it means no such variable exists.
The value of the variable may be calculated during compilation and stored as an immediate value in the application code.

[qtbeginner0]

...may be calculated during compilation and stored as an immediate value in the application code.

Does this also apply to a variable which has to have different values through out the using of the application?

[wysota]

Does this also apply to a variable which has to have different values through out the using of the application?

No, because such variable will never be "optimized out".

[qtbeginner0]

Is there any other reason why the variable could be oprimized out?
Cause the variable "a" is changed few times while using the application.
(btw. don't know if this makes a difference but I debug the release version, cause the bug seems to be present in release version only)
optimized.jpg

[qtbeginner0]

Finally I got the cause of the bug.

The problem is that the second value (sa) is calculated some lines before the calculation of the variable a. Thus the value of sa is stored as a 64bit value in memory, whereas the variable a (which is calculated the same way using the same values) remains in the floating point register (which is 80bit wide) and is not stored into memory.

So the original value of sa when calculated and still in a floating point register (80bit) is:
5.87503620442306551...
0x4001bc004bed1a046600 (hex)
01000000000000011011110000000000010010111110110100 011010000001000110011000000000 (binary)

but when you look at the same value BUT stored in memory (as a 64bit value) you get this:
5.875036204423065733...
0x401780097da3408d (hex)
01000000000101111000000000001001011111011010001101 00000010001101 (binary)

when you compare the mantissa/fraction of both values in binary you get:
010000000001________01111000000000001001011111011010001101000000100011 01
01000000000000011___01111000000000001001011111011010001101000000100011 0011000000000

you can see that the value is rounded up (the mode my cpu uses is "Round to nearest") when moving from the floating point register (80bit) to memory (64bit).
more on rounding to nearest


So all values of the variable sa with 5,6,7,c,d,e,f at the third nibbel from the end will result in rounding up.
0x4001bc004bed1a046X00 (hex) (X=third nibbel from the end)

Finally, when the value which was rounded up is subtracted from the original value (which is smaller than the rounded up), the result is a NEGATIVE, very small number.
(normally I would expect the rsesult of the subtraction beeing tiny or zero but not negative )

fmod((a - sa) + 2.*M_PI,2.*M_PI);

fmod((a - sa) + 2.*M_PI,2.*M_PI);

To copy to clipboard, switch view to plain text mode 

and that's the cause of the bug.

thanks for all your comments.