无意之间在网上看到的一篇好文章

下来看看

果然好文章。在GCC4.3@Ubuntu下重现了这个Bug……

怎么下载了全是乱码啊？

这个BUG确实是因为inline函数引起的，但是我仍然不明白gcc为什么要把endpoint.udpPort_ = 0;
放到后面操作，这篇文章没有说清这种乱序是如何优化流水线的，而且文章中的反汇编像是作者修改后的，因为02级优化包含了延迟退栈，让人看着不爽。

这是我用O2优化后反汇编的结果：
 8048423:       8b 1d d0 96 04 08       mov    0x80496d0,%ebx     <－－%ebx ＝ endpoint
 8048429:       89 4d f8                mov    %ecx,-0x8(%ebp)
 804842c:       66 c7 05 d2 96 04 08    movw   $0x0,0x80496d2     <－－($endpoint+2) ＝ 0
 8048433:       00 00
 8048435:       89 1c 24                mov    %ebx,(%esp)
 8048438:       e8 b7 fe ff ff          call   80482f4 <srand@plt>
 804843d:       a1 d0 96 04 08          mov    0x80496d0,%eax
 8048442:       89 5c 24 04             mov    %ebx,0x4(%esp)
 8048446:       c7 04 24 34 85 04 08    movl   $0x8048534,(%esp)   <－－format_string_addr
 804844d:       89 44 24 08             mov    %eax,0x8(%esp)
 8048451:       e8 ce fe ff ff          call   8048324 <printf@plt>

第三条指令movw   $0x0,0x80496d2就是乱序的结果，放到第一条前面结果就是对的，也不见得会中断流水线。

通常-O2是最有效的优化，-O3在-O2的基础上加入了循环展开和处理器相关优化，因为-O3还不成熟效率往往比-O2还要底。最好是在-O2的基础上使用选项-f{flag},-m{flag}自定义适合硬件结构的优化。找到一篇比较全面的文章：http://blog.

即使代码不出错编译器也可能出错，即使编译器不出错OS也可能出错，OS不出错时硬件可能出错，bug无穷尽。。。

据说VC的inline也有这个问题，导致了release和debug版本可能出现不同...

我的一个VC工程代码中没有使用inline，也 导致了release和debug版本可能出现不同