这是由于未定义的行为,您正在访问数组mc的循环的最后一次迭代的边界。一些编译器可以围绕没有未定义的行为的假设执行积极的循环优化。逻辑将类似于以下内容:
>访问mc超出范围是未定义的行为
>假设没有未定义的行为
>因此, 4总是为真,否则mc [di]会调用未定义的行为
jmp .L6
这几乎与GCC pre-4.8 Breaks Broken SPEC 2006 Benchmarks中概述的情况相同。本文的意见非常好,值得读。它注意到clang抓住了在文章中使用-fsanitize = undefined的情况,我不能为这种情况下重现,但gcc使用-fsanitize = undefined does(see it live)。可能是围绕一个优化器,围绕未定义的行为推理的最臭名昭着的错误是Linux kernel null pointer check removal。
虽然这是一个积极的优化,重要的是要注意,因为C标准说未定义的行为是:
behavior for which this International Standard imposes no requirements
这基本上意味着任何可能,它注意到(强调我的):
[…]Permissible undefined behavior
ranges from ignoring the situation completely with unpredictable results, to behaving during translation or
program execution in a documented manner characteristic of the environment (with or without the issuance of
a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).[…]
为了从gcc获得警告,我们需要将cout移到循环外,然后我们看到以下警告(see it live):
warning: iteration 3u invokes undefined behavior [-Waggressive-loop-optimizations]
for(di=0; di<4;di++,delta=mc[di]){ }
^
这可能足以向OP提供足够的信息来确定发生了什么。这样的不一致是典型的我们可以看到与未定义的行为的类型的行为。为了更好地理解为什么这样的警告可能是不一致的面对未定义的行为Why can’t you warn when optimizing based on undefined behavior?是一个很好的阅读。
注意,-fno-aggressive-loop-optimizations在gcc 4.8 release notes中有记载。