Specify: int->float and f32->f64 round to nearest, overflow to infinity

[hanna-kruppe]

As suggested by @Centril, this issue is for getting @rust-lang/lang approval for rust-lang/reference#607 (Note: will update that patch to explicitly talk about overflow behavior, once approved here)

cc #62175

Detailed proposal

The following casts:

• (expr: iM) as fN
• (expr: uM) as fN
• (expr: f64) as f32

all can see values that cannot be represented losslessly in the destination type, e.g.:

• i32::MAX is not exactly representable as f32 (though it is less than f32::MAX, so it can be rounded to a finite float)
• u128::MAX is larger than f32::MAX, so it cannot even be rounded to a nearby finite float (it "overflows")
• f64 obviously has more precision than f32, so this cast has to round (infinities and NaNs can be carried over to f32, so this is only about finite numbers)

These cases are not unsound any more (see #15536), but currently the rounding mode is explicitly "unspecified" in the reference. What happens on overflow (e.g. u128::MAX as f32) is also not specified explicitly anywhere AFAICT. I proposed to define these casts as follows:

• rounding mode: to nearest, ties to even (see IEEE 754-2008 §4.3.1)
• on overflow: return infinity (with the sign of the source)

Rationale

Leaving the behavior of this core part of the language unspecified only hinders Rust programmers in using them and causes uncertainty and (de jure) non-portability. They should be defined as something, and I argue (round to nearest, overflow to infinity) is the most obvious, most consistent, and most useful choice:

• IEEE 754-2008 prescribes round-to-nearest as the default rounding mode and returning (+/-) infinity as the default behavior on overflow (see §4.3.3, §7.4 in IEEE 754-2008).
• This rounding mode and overflow behavior gives the closest possible result (which is of course why IEEE 754 makes it the default).
• Other operations in Rust (e.g., string parsing) and conversions in other languages (e.g., Java) also default to these behaviors.
• LLVM and hardware support this rounding mode and overflow handling natively, so it is also efficient.

[gnzlbg]

IEEE 7.2 mentions:

The overflow exception shall be signaled if and only if the destination format’s largest finite number is exceeded in magnitude by what would have been the rounded floating-point result (see 4) were the exponent range unbounded.

In addition, under default exception handling for overflow, the overflow flag shall be raised and the inexact exception shall be signaled.

So I wonder whether "panicking on overflow" (e.g. when debug-assertions=on) was considered as a potential alternative, and if so, what were the tradeoffs.

[hanna-kruppe]

Here's some reasons for not panicking:

• Panics are entirely unprecedented for as casts (see also discussion in floating point to integer casts can cause undefined behaviour #10184).
• We'd need to add a new API for the conversion that allows people to choose infinity-on-overflow when they want it.
• Arguably, if this conversion errors on overflow, it should do so by returning Result, not panicking. Of course, that's not possible for as.
• Generally as casts are for unchecked, potentially quite lossy casts (consider casting to from larger to smaller integer types, which doesn't ever check for overflow), so it would be weird to start checking in this one particular case.
• Panicking is arguably incompatible with the current wording in the reference, which implies that rounding happens, and overflow -> inf is arguably rounding.
• It would slow down an operation that is probably common in some performance sensitive code paths.

I should also note that IEEE 754 cannot possibly serve as justification for such behavior, despite the suggestive quote.

In the context of that standard, "exception" and "signaling an exception" does not imply trapping, aborting, or otherwise diverting execution flow, but simply refers to an exceptional circumstance that by default is handled by supplying a sensible result (rounded result in the case of inexact, returning an infinity in the case of overflow).

Other handling of these exceptions is possible, including diverting execution flow, but as far as IEEE 754 is concerned, there is no distinction between exceptions raised from e.g. casts versus arithmetic. So in this framework, if you want to panic on overflow, it should happen on every result that overflows, including e.g. exp(HUGE_VAL), f64::MAX * f64::MAX, and "1e1000".parse::<f64>().unwrap(). Needless to say, such a sweeping change to the default behavior is neither desirable as nor backwards compatible.

The overflow flag that is to be raised refers to floating point exception flags, which we do not currently expose in any way in Rust (and this too would be a much broader discussion than about just casts).

[gnzlbg]

I can't find the second part of your quote anywhere in the standard (and certainly not in §7.3), but here's some reasons for not panicking:

I am reading it from here, "Section 7.4 Overflow" (pages 37-38). The second part is the last sentence of Section 7.4 which comes after the page break.

In the context of that standard, "exception" and "signaling an exception" does not imply trapping, aborting, or otherwise diverting execution flow, but simply refers to an exceptional circumstance that by default is handled by supplying a sensible result (rounded result in the case of inexact, returning an infinity in the case of overflow).

That clarifies some of the doubts I had. Section 7.2 states that invalid operations are signaled using a NaN, so I (incorrectly) supposed that, when Section 7.4 said "signaling", a NaN would be returned, but then that same section states a default result is returned (+-INF), so I supposed that overflow would be signaled in some other way, e.g., by setting an overflow flag in some register that one can check. Otherwise one can't know whether overflow happen - e.g. if f64 as f32 returns +INF, did overflow happened because, e.g., f64 == f64::MAX, or was f64 == +INF in which case no overflow happened?

[hanna-kruppe]

Oops,I just noticed I've pulled up the 1985 version of the standard today, sorry for the confusion. I see the wording you quoted now (but my explanation for why it doesn't support panicking still holds). This also resulted in the references in the top comment being wrong, corrected that now.

Section 7.2 states that invalid operations are signaled using a NaN

NB: the correct standardese is: by default, when an inexact operation is signaled, the operation returns a quiet NaN.

so I supposed that when Section 7.4 said "signaling" a NaN would be returned

It doesn't. It signals an inexact exception in the default handling, but that has nothing to do with returning NaNs. A "signaling NaN" is just a kind of NaN that causes some operations to signal an invalid operation exception when they see it, in contrast to quiet NaNs that usually don't cause that (see §6.2).

I supposed overflow would be signaled in some other way, e.g. by setting an overflow flag in some register that one can check. Otherwise one can't know whether overflow happen - e.g. if f64 as f32 returns +INF, did overflow happened because, e.g., f64 == f64::MAX, or was f64 == +INF?

The overflow flag is raised (set) as part of the default exception handling. But as I mentioned (and, I think, discussed with you in the past), Rust does not currently support users reading the flags, so they effectively don't exist in Rust. I'd like to change this eventually but again, far out of scope (and currently infeasible to implement due to LLVM limitations).

[joshtriplett]

Staring at the proposal for a while, and thinking about it further, I think if we document the assumption we're making (as well as noting all the cases we're covering like saturating to infinity) then I don't have a problem signing off on this.

In addition to the documentation changes already requested in the other issues, this needs to explicitly document the assumption that it'll be possible to set hardware floating-point modes to match Rust's expectations on rounding, and that we understand this could potentially limit our ability to use hardware floating point on some future platform that can't support that assumption.

[Havvy]

Where would you document the assumption that it's possible to set the hardware FP modes? That seems to be more of a rule about developing Rust compilers than it does about the language itself. Are other similar restrictions documented anywhere?

[hanna-kruppe]

When I was discussing with @joshtriplett on Discord they said to put these notes in the reference. I don't have strong opinions on where it goes, I just want to know what I have to add where to get this issue settled. Can you two (& anyone else who has strong opinions on the matter) please find some consensus about that so I know what patch(es) to write?

[Centril]

It's a bit odd to note in the reference what expectations on hardware that exist for Rust since that isn't necessary for the purposes of a definitional interpreter / abstract machine. That said, I suppose we can add a lightweight note about what it means for rustc? perhaps the rustc guide is a better place for this note?

[Havvy]

Wherever we note this assumption by Rust, we should also make note that we assume that pointer width is at least 16 bits (via impl Into<isize> for i16) as well.