about summary refs log tree commit diff
path: root/src/test/debuginfo/enum-thinlto.rs
diff options
context:
space:
mode:
authorMazdak Farrokhzad <twingoow@gmail.com>2019-12-06 23:26:55 +0100
committerGitHub <noreply@github.com>2019-12-06 23:26:55 +0100
commit62528d86b01f6d595759d9974413fd2c9055af30 (patch)
treef82c3a048db52021b8d2294a8ff011d59643b122 /src/test/debuginfo/enum-thinlto.rs
parent2bd35c065cb097d1ea6480c372ab9b5eea358cee (diff)
parenta213ff82998ef91fa793883c2f2ebbc574967500 (diff)
downloadrust-62528d86b01f6d595759d9974413fd2c9055af30.tar.gz
rust-62528d86b01f6d595759d9974413fd2c9055af30.zip
Rollup merge of #66841 - SimonSapin:float_round_unchecked_to, r=rkruppe
Add `{f32,f64}::approx_unchecked_to<Int>` unsafe methods

As discussed in https://github.com/rust-lang/rust/issues/10184

Currently, casting a floating point number to an integer with `as` is Undefined Behavior if the value is out of range. `-Z saturating-float-casts` fixes this soundness hole by making `as` “saturate” to the maximum or minimum value of the integer type (or zero for `NaN`), but has measurable negative performance impact in some benchmarks. There is some consensus in that thread for enabling saturation by default anyway, but provide an `unsafe fn` alternative for users who know through some other mean that their values are in range.

<del>The “fit” wording is copied from https://llvm.org/docs/LangRef.html#fptoui-to-instruction, but I’m not certain what it means exactly. Presumably this is after rounding towards zero, and the doc-test with `i8::MIN` seems to confirm this.</del> Clang presumably uses those LLVM intrinsics to implement C and C++ casts, whose respective standard specify that the value *after truncating to keep its integral part* must be representable in the target type.
Diffstat (limited to 'src/test/debuginfo/enum-thinlto.rs')
0 files changed, 0 insertions, 0 deletions