gcc 4.2 の重大なバグ: uyota 匠の一手

元々は、Silent gcc 4.2.0 loop optimization bug with -O2 で見つけられたバグ。こちらの方が、症状は具体的で分かりやすい。

I did some more stripping and it turns out this is the problem

| int
| main(int argc, char *argv[])
| {
|         int i;
|         int numbers[4] = { 0xdead, 0xbeef, 0x1337, 0x4242 };
| 
|         for (i = 1; i <= 12; i++) {
|                 if (i <= 4)
|                         printf("%d: %x\n", i, numbers[i-1]);
|                 else if (i >= 7 && i <= 9)
|                         printf("MUST BE HERE!!! %d\n", i);
|         }
| }

When you increase the size of the array to 6 or higher, it does what you
want. It clearly looks like a compiler bug; the size of the array
shouldn't have an effect on the amount of iterations. 

簡単にまとめると、ループの数が、配列の大きさによって変わってしまう。ループを回す回数を配列によって、決めることも多いので、このバグはある意味、重症だろう。一応、配列に対してループを回す大部分は、配列の要素数分だけ回すことが多いのも事実なのを付け加えておく。違う言い方をすれば、ほとんどの場合は影響は無いだろうと。

このバグを gcc4.2 で回避するには、 -fno-tree-vrp (value range propogation)を使うと、この型の最適化を抑制する。

また、このバグは最近直されたばかりだ。次のリリースの一部に入ったらしい。そして、gcc 4.2.1 のリリースが七月十三日に予定されていると聞く。