帮朋友调试了一个很奇怪的BUG，呵呵。稍微记录一下，再次提醒自己编译器是不可靠的。

代码类似这样：

DWORD dwSub0, dwSub1;

dwSub0 = dwSub1 = 0;

DWORD dwLoop1 = 0, dwLoop2 = 0;

for (dwLoop1 =0; dwLoop1 <7; ++ dwLoop1)

{

++dwSub0;

         for (dwLoop2 =0; dwLoop2 <7; ++ dwLoop2)

         {

                   ++dwSub1;

                   //Do something

         }

}

Debug情况下一切正常，执行完循环之后，dwSub0=7,deSub1=49。但是Release情况下，dwSub0和dwSub1的值都是7。

VC6编译器在特定情况下，优化的结果变为：

dwLoop1和dwLoop2都被初始化为0xFFFFFFA0，每次循环加上0x20，并且和0x80比较，用jb跳转。

最后跳转的地方汇编代码像这样：

eax, [esp+10h]       ;[esp+10h]是dwLoop2

add     edi, 328h      

add     eax, 20h

cmp     eax, 80h

mov     [esp+10h], eax

jb      loc_54E19B      ; ++dwSub1;问题来了！！！

mov     ecx, [esp+1Ch]     ;[esp+1Ch]是dwLoop1

add     ecx, 20h

cmp     edi, offset 00EFD564h

mov     [esp+1Ch], ecx

jl      loc_54E187      ; ++dwSub0;

因为是要循环7次，编译器把dwLoop2初始化为-60，每次加0x20，和0x80比较，正好是循环7次。这样估计是为了在接下来的代码里面重用dwLoop1和dwLoop2。不过使用JB指令来做跳转就发生错误了。由于JB指令只判断CF是否为1，是作无符号比较，所以这里产生了错误，内层循环每次都只会执行一次就退出到外层循环了。而正确的情况应该使用有符号的jl。

至此，问题暂时算是明了了。可能是在某些极特殊的情况下，VC的优化策略有些BUG。而且据朋友说在VC2003下面编译也有同样的错误，就是说可能在2003及以前的VC编译器中存在同样一个错误。2005之后的就不能确定了。

通过#pragma optimize(“”,off)、#pragma optimize(“”,on)关闭这个函数的优化之后，问题解决。

这个问题再次向我们提醒了一件事情，编译器也并不总是可靠的，往往我们在面对一些奇怪的无法解释的BUG的时候，不妨回过头来考虑是否是其他原因导致的，包括编译器、硬件、执行的软件环境，等等。