nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-12-04 04:39:16 +00:00
Code Issues Packages Projects Releases Wiki Activity
549d85d13f
rust/tests/codegen/unchecked-float-casts.rs

37 lines
820 B
Rust
Raw Normal View History

Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-18 01:42:22 +00:00
// This file tests that we don't generate any code for saturation when using the
// unchecked intrinsics.
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-09 00:14:00 +00:00
[AUTO_GENERATED] Migrate compiletest to use `ui_test`-style `//@` directives
2024-02-22 12:10:29 +00:00
//@ compile-flags: -C opt-level=3
//@ ignore-wasm32 the wasm target is tested in `wasm_casts_*`
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-09 00:14:00 +00:00
#![crate_type = "lib"]
// CHECK-LABEL: @f32_to_u32
#[no_mangle]
pub fn f32_to_u32(x: f32) -> u32 {
// CHECK: fptoui
// CHECK-NOT: fcmp
// CHECK-NOT: icmp
// CHECK-NOT: select
Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-18 01:42:22 +00:00
unsafe { x.to_int_unchecked() }
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-09 00:14:00 +00:00
}
// CHECK-LABEL: @f32_to_i32
#[no_mangle]
pub fn f32_to_i32(x: f32) -> i32 {
// CHECK: fptosi
// CHECK-NOT: fcmp
// CHECK-NOT: icmp
// CHECK-NOT: select
Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-18 01:42:22 +00:00
unsafe { x.to_int_unchecked() }
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-09 00:14:00 +00:00
}
#[no_mangle]
Make saturating u128 -> f32 casts the default behavior ... rather than being gated by -Z saturating-float-casts. There are several reasons for this: 1. Const eval already implements this behavior. 2. Unlike with float->int casts, this behavior is uncontroversially the right behavior and it is not as performance critical. Thus there is no particular need to make the bug fix for u128->f32 casts opt-in. 3. Having two orthogonal features under one flag is silly, and never should have happened in the first place. 4. Benchmarking float->int casts with the -Z flag should not pick up performance changes due to the u128->f32 casts (assuming there are any). Fixes #41799
2017-11-09 23:24:05 +00:00
pub fn f64_to_u16(x: f64) -> u16 {
// CHECK: fptoui
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-09 00:14:00 +00:00
// CHECK-NOT: fcmp
// CHECK-NOT: icmp
// CHECK-NOT: select
Define UB in float-to-int casts to saturate - Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-04-18 01:42:22 +00:00
unsafe { x.to_int_unchecked() }
Saturating casts between integers and floats (both directions). This affects regular code generation as well as constant evaluation in trans, but not the HIR constant evaluator because that one returns an error for overflowing casts and NaN-to-int casts. That error is conservatively correct and we should be careful to not accept more code in constant expressions. The changes to code generation are guarded by a new -Z flag, to be able to evaluate the performance impact. The trans constant evaluation changes are unconditional because they have no run time impact and don't affect type checking either.
2017-10-09 00:14:00 +00:00
}
Reference in New Issue Copy Permalink