アプリケーションをリリース モードとデバッグ モードでコンパイルすると、異なる浮動小数点値が生成されます。私が見つけた唯一の理由は、バイナリ トレース ログを保存したことと、リリース ビルドのログがデバッグ ビルドからわずかにずれていることです。32 ビット浮動小数点値の下位 2 ビットが約 1/2 異なるようです。ケースの。
この「違い」はバグだと思いますか、それともこの種の違いが予想されますか。これはコンパイラのバグですか、それとも内部ライブラリのバグですか。
例えば：
LEFTPOS and SPACING are defined floating point values.
float def_x;
int xpos;
def_x = LEFTPOS + (xpos * (SPACING / 2));
問題は X360 コンパイラに関するものです。
リリース モードでは、別の FP 戦略が設定されている場合があります。必要な最適化のレベルに応じて、さまざまな浮動小数点演算モードがあります。たとえば、MSVC には、厳密、高速、および正確なモードがあります。
PC では、浮動小数点レジスタが 80 ビット幅であることを知っています。したがって、計算が完全に FPU 内で行われる場合、80 ビットの精度の利点が得られます。一方、中間結果が通常のレジスタに移動されて戻されると、32 ビットに切り捨てられ、異なる結果が得られます。
ここで、リリース ビルドでは中間結果を FPU レジスタに保持する最適化が行われると考えてください。一方、デバッグ ビルドでは中間結果がメモリとレジスタ間で単純にコピーされ、前後にコピーされます。動作に違いがあります。
これが X360 でも発生するかどうかはわかりません。
バグではありません。浮動小数点演算には、一定の不正確さがあります。リリース モードでは、最適化によって操作の順序が変更され、わずかに異なる結果が得られます。ただし、その差は小さいはずです。大きい場合は、別の問題が発生する可能性があります。
私は同僚が、リリース ビルドとデバッグ ビルドで異なるコンパイラ スイッチを見つけるのを手伝いました。
/fp (浮動小数点動作の指定)を見てください。
他の人が指摘したさまざまな浮動小数点モードに加えて、SSE または同様のベクトル最適化がリリースのために有効になる場合があります。浮動小数点演算を標準レジスタからベクトル レジスタに変換すると、結果の下位ビットに影響を与える可能性があります。ベクトル レジスタは通常、標準浮動小数点レジスタよりも狭い (ビット数が少ない) ためです。
バグではありません。このタイプの違いは予想されます。
たとえば、一部のプラットフォームには、メモリに格納されているよりも多くのビットを使用するフロート レジスタがあるため、レジスタに値を保持すると、メモリに格納してメモリから再ロードする場合と比べて、わずかに異なる結果が生じる可能性があります。
他に述べたように、浮動小数点レジスタは浮動小数点よりも精度が高いため、最終結果の精度はレジスタ割り当てに依存します。
一貫性のある結果が必要な場合は、変数を揮発性にすることができます。これにより、結果は遅くなり、精度は低下しますが、一貫性のある結果になります。
コンパイラが浮動小数点演算の順序を変更できるコンパイラ スイッチを設定した場合 (例: /fp:fast)、明らかにバグではありません。
そのようなスイッチを設定しなかった場合、それはバグです。C および C++ 標準では、コンパイラがユーザーの許可なしに操作の順序を変更することを許可していません。
この不一致は、コンパイラの最適化が原因である可能性が非常に高く、これは通常、リリース モードで行われ、デバッグ モードでは行われません。たとえば、コンパイラは実行を高速化するために一部の演算の順序を変更する場合があります。これにより、浮動小数点の結果にわずかな違いが生じる可能性があります。
したがって、バグではない可能性が高いと言えます。これが本当に心配な場合は、デバッグ モードで最適化をオンにしてみてください。