x86_64とARM64でFloat16の変換結果が違った

Thu, 10 Sep 2026 19:11:38 +0900

OmoikaneのBoa移行前検証で、同じBoaとTest262をLinuxのx86_64とARM64で動かしたところ、結果が10ケースだけ違いました。

実行したのは50,595ケースです。

環境	Passed	Failed	Ignored
Linux x86_64	47,606	933	2,056
Linux ARM64	47,616	923	2,056

差が出た10ケースは、すべてFloat16への変換に関係するテストでした。

同じソースと入力なのにCPUが変わるとJavaScriptの結果も変わるのは困ります。何が起きているのか調べました。

原因はfloat16 0.1.5のソフトウェア変換

先に結論を書くと、Rust本体やCPUの浮動小数点仕様の問題ではありませんでした。

Boaが依存していたfloat16 crateのバージョン0.1.5にある、f64からf16へのソフトウェア変換が原因です。

問題のあった0.1.5の実装は、f64の64ビット表現を取得した直後に32ビット右へシフトしていました。

let val: u64 = unsafe { mem::transmute::<f64, u64>(value) };
let x = (val >> 32) as u32;

f16の仮数部は10ビットしかないので、f64の下位ビットは最終結果にはそのまま残りません。

ただし、丸める前に捨ててよいわけではありません。丸め境界より上なのか、ちょうど中間なのかを判定するために、捨てる部分にも非ゼロのビットがあるかという情報が必要です。

0.1.5ではその情報まで先に消していたため、本当は中間値を少し超えている値を、ちょうど中間値だと判定する場合がありました。

一番小さい値で見る

f16で表現できる最小の正の非正規化数は2^-24です。

2^-24 = 5.960464477539063e-8

0との中間は2^-25になります。

2^-25 = 2.98023223876953125e-8

今回の再現値は、その中間よりほんの少しだけ大きい値です。

入力: 2.980232238769532e-8
f64 bits: 0x3e60000000000001

末尾の1があるため、正しく丸めると0ではなく、最小の正のf16である0x0001になります。

ところが下位32ビットを先に捨てると末尾の1が消えます。すると入力がちょうど中間に見えてしまい、最近接偶数丸めによって偶数側の0x0000が選ばれます。

結果に残らないビットでも、丸めの方向を決めるためには必要だったということです。

最小の検証コードを書いた

0.1.5と修正後の0.1.7を同じプログラムから呼び、3個の境界値を比較する検証コードを作りました。

0.1.5はIssueで確認したGit revisionを指定し、0.1.7はcrates.ioのリリースを固定しています。

[dependencies]
float16_015 = { package = "float16", git = "https://github.com/Alexhuszagh/float16.git", rev = "2401a40bbdeac256070324ec954bf268bc8e7be7" }
float16_017 = { package = "float16", version = "=0.1.7" }

確認している部分は次のようになっています。