GCC的BUG讨论

Solidot报道GCC在Linux平台下有一个BUG。但是原文中说只有Linux平台有这个问题是不正确的，经过令狐的实际测试，在HP－UX（GCC 4.0.2），LINUX（UBUNTU，GCC 4.1.2），WINDOWS（GCC 3.4.5）下都存在在这个问题。

为了调查研究一下这个问题究竟是如何造成的，我们一帮人展开了一番讨论，经过对汇编代码的分析，结果看来是GCC的代码优化实现有问题。

测试的C源程序如下：

int main () {
    int i=2;
    if( -10*abs (i-1) == 10*abs(i-1) )
        printf ("OMG,-10==10 in linux!\n");
    else
        printf ("nothing special here\n");
}

在X86 Linux平台下的汇编代码片段如下：

19     mov    DWORD PTR [%ebp-8], 2
20     mov    %edx, DWORD PTR [%ebp-8]
21     mov    %eax, %edx
22     sal    %eax, 2
23     add    %eax, %edx
24     add    %eax, %eax
25     sub    %eax, 10
26     mov    %edx, %eax
27     sar    %edx, 31
28     mov    %ecx, %edx
29     xor    %ecx, %eax
30     sub    %ecx, %edx
31     mov    %eax, DWORD PTR [%ebp-8]
32     imul   %eax, %eax, -10
33     add    %eax, 10
34     mov    %edx, %eax
35     sar    %edx, 31
36     xor    %eax, %edx
37     sub    %eax, %edx
38     cmp    %ecx, %eax
39     jne    .L2

（完整的代码在这里：X86 Linux，HP-UX——由令狐虫友情提供）

代码并不难理解：

其中 DWORD PTR [%ebp-8] 就是变量 i 。21行到25行之间是计算 i * 10 - 10 ，结果保存在 eax 中。26行到30行是 abs() 函数的实现，我以前对这个倒还真没研究过，现在一看之下发现这个实现还真是有创意啊（回头细说）。31行到33行是计算 i * -10 + 10 ，结果保存在 eax 中。34行到37行同样是 abs() 函数的实现。38行到39行是比较跳转。

所以结果已经很清楚了，GCC把：

-10 * abs( i - 1 ) 和 10 * abs( i - 1 )

优化成了：

abs( -10 * i + 10 ) 和 abs( 10 * i - 10 )

结果当然就不正确了。

结论就是：不是 abs() 函数实现的问题，也不是代码解析的问题，是优化的问题——编译器最容易出问题的地方就是优化。

现在最不能理解的就是：这样做并不见得更“优”，何必要这样“优化”呢？

补充(Rev.2)：

后来经三火指点，这种优化被称为Const Foldering，也就是说把常量提取出来在编译时计算，以优化运行时的性能。本来对于取绝对值这种情况是不应该这么做的，因为 abs() 本身是一个函数，但是与令狐讨论后，他认为GCC在这里实际上是把它优化为一个操作，所以同时对它进行了Const Foldering。

关于在这个Const Foldering的BUG，有人提供了一个补丁：《[PATCH] Fix PR34130, extract_muldiv broken》，其中的修正代码是这一段：

*** fold-const.c (revision 130238)
--- fold-const.c (working copy)
*************** extract_muldiv_1 (tree t, tree c, enum t
*** 6095,6100 ****
--- 6095,6103 ----
              }
            break;
          }
+       /* If the constant is negative, we cannot simplify this.  */
+       if (tree_int_cst_sgn (c) == -1)
+         break;
        /* FALLTHROUGH */
      case NEGATE_EXPR:
        if ((t1 = extract_muldiv (op0, c, code, wide_type, strict_overflow_p))

在这个补丁代码里，是简单地对要处理的常量进行判断，如果是负数就跳过Const Foldering优化部分。但我和令狐都认为，这种解决方案只是一种权宜之计，是一种明显的坏味道。

我觉得根本的解决方案是将 abs() 从Const Foldering优化的操作列表中去除——但是将 abs() 优化为一个操作的确是很有用的，如果Const Foldering是对所有操作都进行优化的话，这种修改也可能会带来别的坏味道。我不知道GCC中还把什么函数优化为操作，但是如果是对所有操作进行 Const Foldering的话，潜在风险还会有的，因为Const Foldering只对线性函数正确，而 abs() 出问题正是因为它是一个非线性函数。

补充(Rev.3)：

关于优化选项的问题，我们刚才又做了一下研究。使用 -O0 选项关闭优化，仍然生成与无优化选项类似的代码，看来这种是属于默认优化的部分。使用 -O1 和 -O2 选项生成的目标代码很相似，都是高度优化的（但结果仍然是错误的）：

        mov    DWORD PTR [esp], OFFSET FLAT:LC0
        call   _puts

（完整的代码在这里：X86 Linux——由Mike友情提供）

可见只剩下一句 printf("OMG..."); 。这也就意味着这个最优化代码是在Const Foldering 之后，编译器又发现了 i 本质上也是一个常量，所以优化成了现在这个样子。如果编译器是先发现 i 是常量，再作Const Foldering 的话，结果就会是正确的了——令狐昨天已经试过，把 i - 1 换成 1 以后，默认优化生成的代码与现在最优化生成的代码差不多，只不过输出结果是正确的 printf("nothing..."); 。

＝＝＝＝附录的分割线＝＝＝＝

附一段关于这个 abs() 函数实现的说明：

整数取绝对值的方法基本上就是判断是否小于0，如果是则取负，否则直接返回。GCC里的实现则比较巧妙，没有判断跳转的过程（我猜测是基于CPU运行优化考虑）。它的做法是用 sar 指令填充符号位得到一个数，对于正数，这个符号数为0，对于负数，这个符号数为全1（即-1）。然后用这个符号数与原数异或，如果是正数将不变（与0异或不变），如果是负数将取反（与1异或取反）。最后将异或结果减符号数，对于正数来说，减0原值仍然不变，对于负数来说，减-1相当于+1——在补码中，一个整数取反加1的结果正是等于对其取负。于是实现了绝对值的计算。

要汗一下的是，我今天刚在豆瓣上跟人说：不做底层工作不需要了解汇编。结果这就碰到一个反例。

Search

友情链接

标签