c++ - 在 Release模式下，代码行为不如预期

Question

以下代码在 Debug模式和 Release模式下产生不同的结果(使用 Visual Studio 2008):

int _tmain(int argc, _TCHAR* argv[])
{

    for( int i = 0; i < 17; i++ ) 
    { 
        int result = i * 16;

        if( result > 255 )
        {
            result = 255;
        }

        printf("i:%2d, result = %3d\n", i, result) ; 
    } 

    return 0;
}

Debug模式的输出，和预期的一样:

i: 0, result =   0
i: 1, result =  16
(...)
i:14, result = 224
i:15, result = 240
i:16, result = 255

Release模式的输出，其中 i:15 结果不正确:

i: 0, result =   0
i: 1, result =  16
(...)
i:14, result = 224
i:15, result = 255
i:16, result = 255

在 Release模式下，在Visual Studio中选择“优化->不优化”，输出结果是正确的。但是我想知道为什么优化过程会导致错误的输出。

---

更新:

根据 Mohit JainBy 的建议，打印:

printf("i:%2d, result = %3d, i*16=%d\n", i, result, i*16) ;

Release模式输出正确:

i: 0, result =   0, i*16=0
i: 1, result =  16, i*16=16
(...)
i:14, result = 224, i*16=224
i:15, result = 240, i*16=240
i:16, result = 255, i*16=256

Answer 1

这很有趣，至少从历史的角度来看是这样。我可以重现 VC 2008 (15.00.30729.01) 和 VC 2010 (16.00.40219.01) 的问题(针对 32 位 x86 或 64 位 x64)。我尝试从 VC 2012 (17.00.61030) 开始的任何编译器都不会出现此问题。

我用来编译的命令:cl/Ox vc15-bug.cpp/FAsc

由于 VC 2008(和 2010)已经相当老了，而且修复程序已经存在好几年了，我认为除了使用更新的编译器之外，你不能指望微软采取任何行动(尽管也许有人可以提出解决方法)。

问题是判断值是否应该强制为 255 的测试是基于循环计数而不是 i * 16 的实际结果来完成的表达。并且编译器只是在应该开始将值强制为 255 时计算错误。我不知道为什么会这样——这只是我看到的效果:

; 6    :    for( int i = 0; i < 17; i++ ) 

  00001 33 f6        xor     esi, esi
$LL4@main:
  00003 8b c6        mov     eax, esi
  00005 c1 e0 04     shl     eax, 4

; 7    :    { 
; 8    :        int result = i * 16;
; 9    : 
; 10   :        if( result > 255 )

  // the value `esi` is compared with in the following line should be 15!
  00008 83 fe 0e     cmp     esi, 14            ; 0000000eH
  0000b 7e 05        jle     SHORT $LN1@main

; 11   :        {
; 12   :            result = 255;

  0000d b8 ff 00 00 00   mov     eax, 255       ; 000000ffH
$LN1@main:

; 13   :        }

更新:我安装的早于 VC 2008 的所有 VC 版本都有相同的错误，除了 VC6 - 编译程序会导致 VC6 编译器崩溃:

vc15-bug.cpp(10) : fatal error C1001: INTERNAL COMPILER ERROR

所以这是一个在 MSVC 中以一种或另一种形式存在超过 10 年的错误!