floating point to floating point casts have undefined behaviour

[huonw]

If the value cannot fit within the destination type, ty2, then the results are undefined.

http://llvm.org/docs/LangRef.html#fptrunc-to-instruction

e.g. 1e300f64 as f32

cc #10184, #10185

[huonw]

Nominating

[pcwalton]

I think this is not a 1.0 issue. There is no reasonable backwards incompatible language change we can make here to fix it. The only thing to do is to change the LLVM semantics here to not be UB, but rather be an undefined value.

[zwarich]

@pcwalton the LLVM semantics here are that the result is an undefined value, not that the instruction exhibits undefined behavior. Otherwise you wouldn't be able to hoist an fptrunc out of a loop.

[pcwalton]

OK, then I believe this is not a bug, just something to remember to note in the spec.

[pnkfelix]

Assigning P-high, not 1.0 milestone, by the same reasoning as #10184 and #10185.

[thestinger]

@zwarich: Rust allows undefined behaviour if you have an undefined value. An undefined value has no live range so it doesn't correspond to a reserved register with a preserved value and can vary between reads. That means something like xs[undef] can do an out-of-bounds index, because there's nothing forcing it to have the same value between the check and the read.

[zwarich]

@thestinger That's a good point, but that just makes it like the other bugs that aren't in 1.0.

[thestinger]

Programs can be written depending on the value of undefined behaviour, and changing it to either fail or provide a specific result will break those programs. This isn't C where undefined behaviour is a problem in user code.

[bombless]

We may need a UB label for such issues IMO