ありがとうございます。とても勉強になりました。

> -O3については、そもそもtest(b)の呼出はせず、
> そもそも浮動小数点関連の計算すら一切行わずに直接1を
> 出力しています。
> コンパイル時にすべての計算を終えてしまい、その際、
> 2 と 2 / 100.0 * 100.0 は同一だと判定したのでしょう。
最近のコンパイラはそこまでやるか！

> なぜ結果が一定しないかを考えるのは楽しいですが、
御意。

完全に余談ですが

>最近のコンパイラはそこまでやるか！
なんかで、
int fac(int n){
if(n<=1)
return 1;
else
return fac(n-1)*n;
}
を作ってfac(5)とか書いたら最適化で全部展開されて定数になって出たって話も
聞いた覚えが…

最適化による計算内容の変動も面白いものがありますよね。

>最近のコンパイラはそこまでやるか！

最近のコンパイラの最適化はかなり賢いので
人間がアセンブラで組むよりもよっぽど速かったりしますね。
昔のコンパイラだと高速化が必要とかだとアセンブラ必須でしたけど。
今のコンパイラだと相当の達人で無いと人間が負けるんじゃないかなぁ。

余談は続く。

> 今のコンパイラだと相当の達人で無いと人間が負けるんじゃないかなぁ。
確かにそうですね。
インテルのコンパイラなんてHT用に命令の順序を変更するなんてことも聞いていますし。
この辺になるとCPUの内部アーキテクチャーが分からないとどうにもならない。

ところで、今回の件で、
> double e = test(b);
> cout << (c == e) << endl;
> cout << (c == test(b)) << endl;
の e に volatile をつけるとコンパイルすると、どうなるんでしょう。
ちょっと興味があります。
# gcc は入っていないので...

余談です。

> 今のコンパイラだと相当の達人で無いと人間が負けるんじゃないかなぁ。
>> 確かにそうですね。
>> インテルのコンパイラなんてHT用に命令の順序を変更するなんてことも聞いています
>> し。
>> この辺になるとCPUの内部アーキテクチャーが分からないとどうにもならない。
日立系のCPU（H8,SH,SH2,SH3,SH4)はC言語が優勢ですね。
PIC/AVR関連も言語が使えるようになってます。
#　僕はPICのC言語にいまいち慣れてないです。
アセンブラは、単純動作でスピード重視の部分に限られるようになるのかも
知れませんね。

> アセンブラは、単純動作でスピード重視の部分に限られるようになるのかも
> 知れませんね。

下手するとそういう領域もコンパイラが吐き出すコード十分と言う事にも
なりかねませんね。
こっちの方面の職人は段々需要が無くなっていくのかも。
コンパイラを書くような人たちは話が別なんでしょうけれど。

さらに余談は続く。

> アセンブラは、単純動作でスピード重視の部分に限られるようになるのかも
> 知れませんね。
電力関係などの特に高信頼性が求められる分野では、組み込みソフトウェアのバグ修正の際に
新旧ROMの照合を行なって修正した部分以外に変更が無いことの確認が求められることがある
そうです。
このような場合、アセンブラでないとなかなか難しいのではないかとも思います。