Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> // Tests saturating float->int casts. See u128-as-f32.rs for the opposite direction. </ins> // compile-flags: -Z saturating-float-casts #![feature(test, i128, i128_type, stmt_expr_attributes)]

Discussion:
Given this code (): It should print . In release mode, that happens, but in debug mode, it prints . The value is mostly irrelevant, it would also work for . cc cc tracking issue
is undefined. It ends up being as in LLVM. This issue is in a similar vein as the float to integer casts. All we really need is a decision on how to handle this. For u128-f32 it seems pretty obvious to simply produce an infinity.
If it is currently UB then maybe needs to be reopened.
to f32 converts just fine.
Yes, because the maximum value of a u64 fits in a f32 fine.
Cross-linking
Don't forget .
Hi! Sorry if this is a stupid suggestion… but as someone who uses u128 (in several cryptographic libraries) and doesn't use floats, I wonder how many users actually need safe casting to floats? Is this something one would do in graphics development? If there isn't much use for it, perhaps a simple fix would be to disallow casts, i.e. they should have to first cast to .
If a new -cast rule is going to be introduced, please make it generic so that it can be naturally extensible to something like or GMP types
Rust is a general purpose programming language and it already has a syntax for doing conversions that one could expect to work on all the primitive types, so it not supporting -casts for only this particular conversion would make the language inconsistent. Furthermore, consider a code like this: Now this macro works just fine for every single integer and float combo. Forbidding it for i/u128 would extend the discrepancy to macros as well. I hope that’s enough of demonstration of a need to keep functionality consistent.
The consistency issue, esp. w.r.t. macros, makes perfect sense. Thanks for taking the time to point that out.
currently generates this LLVM IR: which, on x8664, i686 and aarch64, becomes a call to the compilerrt function Directly calling the function, instead of generating the instruction, seems to be able to hide the UB? The casts to +∞.
It makes no sense to do that over just adding the relevant branches into the IR, because it inhibits pretty much every optimisation with the values involved.

Yes we could do this producing producing (unfortunately the function will always be called, and the cold branch check remains)
gives with . Could the range check placed there as a first step, to prevent a naked being generated? Or just add a lint/error if produces an ? Or wait for miri?
LLVM will want some solution that’s more general and we want to avoid having custom patches in our LLVM, so I do not think that would work. Interesting option, but does not help with code like which is still very UB, even if it does not produce a literal at the moment after the optimisations.
Ignoring LLVM and C/C++ for the moment, IEEE 754 section 5.4.1 "Arithmetic operations" defines and says: Integer to floating-point conversions typically use "to nearest" rounding. IEEE 754 section 4.3.1 "Rounding-direction attributes to nearest" defines "no nearest" and says: fits that condition when converted to . So by IEEE 754 rules, for what that's worth, the result is defined and has the value ∞.
Marking P-medium to match other similar bugs.
has been merged, so there's now an opt-in solution to this issue (). Presumably we'll want to make this behavior the default at some point in the future &ndash; does anyone have opinions on when that should be and what prerequisites there are (if any)?
I'd say we should do a public call, asking people to test the feature and report back. Then if there are no major issues after idk, 2-3 weeks (some people only read the weekly newsletter), we could flip the defaults and allow an opt out. It could stay this way on the nightly channel and if there continue to be no issues, we can let it ride the trains and include it in the next beta to be to the next stable (without an opt out, as it would require a -C option and you won't be able to remove the opt-out again). If we hear about issues while the feature is in the beta channel, we can disable it on the beta channel as well.
Huh, that's a bit more scrutiny than I would have expected. To be clear, in the context of this issue I am only talking about u128 -f32 casts, the float -int direction covered by can and should be rolled out independently.

With that in mind, do you think the change to u128 -f32 casts is more likely to cause regressions than the average bug fix?
I've file a PR () to just make the u128-f32 behavior the default, refocusing the -Z flag to just cover float-int casts. As with any other change, we'll have up to six weeks in nightly and six weeks of beta to find and fix any regressions there may be.
FYI overflowing s/uitofp casts are no longer considered undefined as of So we should be able to drop the extra range checking code somewhere in the future.