这个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无穷尽。。。