Hello,
the original post is nearly 2 years ago, but it seems that the problem
described then still exists at least up to CW Win 8.3:
When the Optimization Level is > 1, long longs are sometimes not
passed on the stack but in a register pair. In this case the value
passed is destroyed (32 bits of the 64 bit contain garbage). This is
really happening in the code, and is not a debugger inspection issue.
I verified this by compiling the entire project without touching a
single source line once for each optimizer level. At 0 and 1, it works
as ist should; at Levels 2-4, long longs get corrupted.
In addition, there seems to be a debugger bug that displays 64bit
values stored in a register pair with longwords swapped.
The debugger problem is a "oops"; I know that debugging optimized code
is not reliable (however sometimes inevitable like here, when trying
to track down why the optimized code behaves differently... The
compiler bug combined with the debugger bug caused this to be very
very time consuming, it cost me a full day :-(
The actual compiler bug however is catastrophic, especially because
there are apparently many cases of passing long longs where everything
works ok, and only under special circumstances it is not. Simply
moving a routine's implementation from one (large) source file to
another (smaller) one has made the difference in my case.
Reading trough the CW Win 9 release notes, I found:
* Fixed bug spilling long longs. If only the upper half was spilled,
only four bytes would be allocated (but addressed at an offset of
4), leading to stack corruption. (WB1-49664) (26 September 2003)
This sounds at least related, but does not exactly match what I see
happening.
As this potentially could have desastrous effects (but for mere luck
apparently did not in the past two years I was using CW 8), I am very
worried using the optimizer at all until I know what's really
happening, and if the WB1-49664 release note entry below means that it
is now fixed.
Thanks for any information about this in advance!
luz
|
