GCCを使用するx86で整数オーバーフローが無限ループを引き起こすのはなぜですか？

次のコードは、GCCの無限ループに入ります。

#include <iostream>
using namespace std;

int main(){
    int i = 0x10000000;

    int c = 0;
    do{
        c++;
        i += i;
        cout << i << endl;
    }while (i > 0);

    cout << c << endl;
    return 0;
}

だからここでの取り決めです：符号付き整数オーバーフローは技術的に未定義の動作です。しかし、x86上のGCCは、オーバーフローでラップするx86整数命令を使用して整数演算を実装します。

したがって、未定義の動作であるにもかかわらず、オーバーフローでラップすることを期待していました。しかし、明らかにそうではありません。それで私は何を逃したのですか？

私はこれを使ってこれをコンパイルしました：

~/Desktop$ g++ main.cpp -O2

GCC出力：

~/Desktop$ ./a.out
536870912
1073741824
-2147483648
0
0
0

... (infinite loop)

最適化を無効にすると、無限ループはなくなり、出力は正しいものになります。Visual Studioもこれを正しくコンパイルし、次の結果を提供します。

正しい出力：

~/Desktop$ g++ main.cpp
~/Desktop$ ./a.out
536870912
1073741824
-2147483648
3

その他のバリエーションは次のとおりです。

i *= 2;   //  Also fails and goes into infinite loop.
i <<= 1;  //  This seems okay. It does not enter infinite loop.

関連するすべてのバージョン情報は次のとおりです。

~/Desktop$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ..

...

Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) 
~/Desktop$ 

だから問題は：これはGCCのバグですか？または、GCCが整数演算を処理する方法について何か誤解しましたか？

*このバグはCで再現されると想定しているため、このCにもタグを付けています（まだ確認していません）。

編集：

これがループのアセンブリです：（私が適切に認識した場合）

.L5:
addl    %ebp, %ebp
movl    $_ZSt4cout, %edi
movl    %ebp, %esi
.cfi_offset 3, -40
call    _ZNSolsEi
movq    %rax, %rbx
movq    (%rax), %rax
movq    -24(%rax), %rax
movq    240(%rbx,%rax), %r13
testq   %r13, %r13
je  .L10
cmpb    $0, 56(%r13)
je  .L3
movzbl  67(%r13), %eax
.L4:
movsbl  %al, %esi
movq    %rbx, %rdi
addl    $1, %r12d
call    _ZNSo3putEc
movq    %rax, %rdi
call    _ZNSo5flushEv
cmpl    $3, %r12d
jne .L5

規格で未定義の動作と記載されている場合、それはそれを意味しますます。何でも起れる。「すべて」には「通常は整数が循環しますが、時々奇妙なことが起こる」ことが含まれます。

はい、x86 CPUでは、整数は通常、期待どおりにラップされます。これはそれらの例外の1つです。コンパイラは、ユーザーが未定義の動作を引き起こさないと想定し、ループテストを最適化します。あなたが本当にラップアラウンドをしたい場合は、合格-fwrapvにg++またはgccコンパイルするとき。これにより、明確に定義された（2の補数）オーバーフローセマンティクスが得られますが、パフォーマンスが低下する可能性があります。

それは簡単です：未定義の動作-特に最適化（-O2）がオンになっている場合-は何が起こってもよいことを意味します。

あなたのコードは-O2スイッチなしで（あなたの）期待通りに動作します。

ちなみにiclとtccでも問題なく動作しますが、そのようなものに依存することはできません...

よれば、この、GCCの最適化は、実際には符号付き整数オーバーフローを利用します。これは、「バグ」が仕様によるものであることを意味します。

ここで注意すべき重要な点は、C ++プログラムはC ++抽象マシン（通常、ハードウェア命令によってエミュレートされる）用に作成されていることです。x86用にコンパイルしているという事実は、これが未定義の動作をしているという事実とはまったく関係ありません。

コンパイラーは、未定義の動作の存在を自由に使用して、最適化を改善します（この例のように、ループから条件を削除します）。実行時にマシンコードがC ++抽象マシンが要求する結果を生成するという要件は別として、C ++レベルの構造とx86レベルのマシンコードの構造の間のマッピングは保証されていません。

i += i;

//オーバーフローは定義されていません。

-fwrapvを使用すると、それは正しいです。-fwrapv

人をお願いします、未定義の動作はまさにそれ、未定義ですです。それは何が起こる可能性があることを意味します。実際には（この場合のように）、コンパイラーはそれを自由に想定できます。ができないをます。呼び出され、それがコードをより速く/より小さくすることができるならそれが好きなことをしてください。実行してはならないコードで何が起こるかは、誰もが推測しています。それは周囲のコードに依存します（それに応じて、コンパイラーは異なるコードを生成する可能性があります）、使用される変数/定数、コンパイラーのフラグなど...コンパイラーは更新されて同じコードを異なる方法で書き込むか、またはコード生成について別の見方をした別のコンパイラーを入手してください。または、別のマシンを入手するだけで、同じアーキテクチャラインの別のモデルでも、独自の未定義の動作が発生する可能性があります（未定義のオペコードを検索します。一部の進取的なプログラマーは、これらの初期のマシンの一部で有用な処理が行われることを発見しました...） 。有るません「コンパイラーは未定義の動作に対して明確な動作を提供します」。実装によって定義される領域があり、コンパイラが一貫して動作することを期待できるはずです。

コンパイラが整数のオーバーフローを「非クリティカル」形式の未定義動作（付録Lで定義）と見なす必要があると指定したとしても、整数のオーバーフローの結果は、より具体的な動作の特定のプラットフォームの約束がない場合、最低でも「部分的に不確定な値」と見なされます。このような規則の下では、1073741824 + 1073741824を追加すると、2147483648、-2147483648、または2147483648 mod 4294967296に一致したその他の値が任意に生成されたと見なされ、追加によって得られた値は、0 mod 4294967296に一致した任意の値と見なされます。

オーバーフローが「部分的に不確定な値」を生成することを許可するルールは、Annex Lの文字と精神に従うために十分に明確に定義されますが、オーバーフローが制約されていない場合に正当化されるのと同じように、コンパイラーが一般的に役立つ推論を行うことを妨げません。未定義の動作。コンパイラーが偽の「最適化」を行うのを防ぎます。多くの場合、その主な効果は、プログラマーがそのような「最適化」を防ぐことを唯一の目的とするコードに余分な混乱を追加することを要求することです。それがいいことかどうかは、自分の視点による。