Serviceを読んで理解し、同意したものとみなします。スタック・オーバーフローはプログラマーとプログラミングに熱心な人のためのQ&Aサイトです。linuxのドキュメントに下記のような説明がありました。いうのを見つけました。ビルドに失敗するそうです。answerは迷ったのですが、リンク先の情報でこちらとさせてもらいました。|15パッと思いつく例としては、末尾最適化を前提とした再帰呼び出しでしょうか。この場合もちろんコンパイルは通りますが、実行時には再帰呼び出しによりコールスタックを食い潰しスタックオーバーフローを引き起こします。関数の再帰呼び出しと末尾呼び出し最適化は、妥当なCコードだが最適化OFFで動かなかくなる(可能性のある)具体例ですね。|9+500x86ではdoubleの演算はFPUに乗る時に80bitに拡張されます(FPU制御レジスタの設定によりますが、Linuxではデフォルトで拡張されるようになっていたはず)。計算の途中結果を一時変数に代入している場合、最適化無しだと代入の際に64bitに丸められてそれが続きの計算で使われますが、最適化ありだとFPUのレジスタに乗っている80bitの値をそのまま使われ、演算結果が異なる可能性があります。通常のプログラムでは浮動小数点数演算の誤差として片付けられるのですが、まれにこの差が問題となることがあります。(与えられた浮動小数点数が表現し得る幅の中で、最も短い10進数表記を求める)アルゴリズムは、64bitのdoubleを扱うためには64bitより大きい精度を必要とします。計算途中で10倍する際に、仮数部の有効数字が1bit余計に必要になるためです。最適化無しで中間結果をdouble型変数に代入すると途中で丸めが入っておかしくなりますが、中間結果が80bitのまま保持されると正しい結果が得られます。Scheme処理系SCMがかつてそのような実装になっていました(参考:1。現在の実装は多倍長整数を使っているのでこの問題はもうありません。)もちろんコード作法的には良くない実装です。コンパイラとプロセッサを決め打ちできる案件ならともかく、今はデスクトップではx86_64の方が主流になり「最適化で80bitのまま保持されることをあてにする」という手法自体obsoleteと考えて良いと思います。floatについてもFPU(80bit)とSSE(32bit)とで演算結果が異なるという問題もありますね。7:443@yohjpさん、固定長の有限浮動小数点数というのは対応する実数と誤差範囲がきちんと定まっているので「正確かつ最適な入出力」というのも定義できます。その仕様のもとで異なる出力が得られたら困ります。ここに書いた件も、テストが失敗することから発見したものでした。いう仕様を必要としない用途の方が多いですが。8:17浮動小数点数だから誤差はつきものと軽く(?)捉えていたのですが、確かに言われてみればですね。ありがとうございます。されてしまうような書き方をしていると、コンパイラやプラットフォームが変わって動作しなくなるというのはありがちで、最適化オプションの指定によっても変わるというのは十分あり得る話だと思います。あたりは、優秀なプログラマでもついやってしまうようで、mrubyでもあったようです。https://codeiq.jp/magazine/2013/12/3556/(ただ、これが最適化オプションの違いで起きるかは不明です。(どちらかといえば、最適化によって壊れることの方が多いですが。個の銅バッジ未定義(undefined)は論外として、未規定(unspecified)と実装依存(implementation-defined)がコンパイラの最適化有無で変化するというのは、原則論としては受け入れ難いですね。|回答スタック・オーバーフローに参加してくれて、ありがとうございます!質問の回答を共有してください。回答を説明し、自分の検討結果も共有してください。意見を述べること(意見を述べるなら、参照リソース、自分の経験で意見をサポートしてください)さらにサポートが必要な場合このヘルプを参考してください。“回答を投稿”をクリックすることで利用規約、プライバシーポリシー、及びクッキーポリシーに同意したものとみなされます。タグが付いた他の質問を参照するか、自分で質問をする。質問のフィードこのRSSフィードを購読するには、このURLをコピーしてRSSリーダーに貼り付けてください。