Memory Corruption, Compiler Bug, Or Not?より。興味深かったので翻訳してみた。
あるメモリ破壊の問題を調べているうちに、私はある１つの関数でスタック上にある引数が常に 2 にセットされることに気付いた。その引数はポインタであるにも関わらず、だ。値が変更された時に、メモリビューウィンドウで色が赤く変わったので気付いた。私はコンパイラのバグを見つけたと考えた。しかしそれは間違いで、コンパイラのバグではなかった。実際のところ、それは最適化コンパイラとデバッガの間の齟齬によるものだった。x86オプティマイザはスタック上の変数が１回しか参照されないことを知っていたため、そのスタックメモリを別のローカル変数として再利用することができた。デバッガはそのことに気付かず、ローカル変数表示でそのメモリの値を元のローカル変数として表示し続ける…ここで混乱が生じている。
ARMでも、同じような状況が発生する。何故なら、最初の４つのレジスタ（R0, R1, R2, R3）が関数の引数として利用されるためだ。関数の引数がいつ「永続的な」レジスタ（例えば、R6）に移されたかをデバッガは知ることができないため、ローカル変数の値を関数の引数のレジスタ値として表示し続ける。
