integer to floating point casts can cause undefined behaviour

[thestinger]

If the value cannot fit in the floating point value, the results are undefined.

-1u64 as f32

[brson]

Nominating.

[pnkfelix]

accepting for P-backcompat-lang, same reasoning as #10184

[pcwalton]

I don't think this is backwards incompatible at a language level. It will not cause code that was working OK to stop working. Nominating.

[thestinger]

@pcwalton: It could cause code to stop working, because the results will change from arbitrary (but perhaps what the program wanted) values to whatever we decide to output when we branch on overflow (INFINITY?). Luckily, most floating point values are f64 so we only need checks on those for casts from 64-bit integers.

[pnkfelix]

changing to P-high, same reasoning as #10183.

But we need to look into this more carefully, I do not yet know what the most recent IEEE 754 says about this case (nor do I know whether LLVM conforms to IEEE 754 2008 in this case ... ) I'd like to investigate that before really claiming to understand this.

[huonw]

Is the example given in the issue actually undefined behaviour? 2⁶⁴ - 1 is in-range for f32 (since the maximum value is ~2¹²⁸), it's just not precisely representable.

Something that would be undefined would be 100000 as f16, since 2¹⁶ = 65536 is the largest value for the half-precision type f16 (that Rust does not yet have).

[Gankra]

I have confirmed on the llvm IRC channel that the intent is that it's UB only if the value is bigger than the biggest finite value. So this is actually not a problem in Rust unless we introduce u128 (which can be bigger than f32's biggest finite) or f16. (i128 is still too small)

[jonas-schievink]

unless we introduce u128

This has now happened

[Gankra]

Sadness

[nagisa]

We already have an issue for this (#41799) which also has some code to reproduce the issue. Re-closing this as duplicate.