floating point to integer casts can cause undefined behaviour

[thestinger]

Current status (2018-11-05)

A flag has been implemented in the compiler, -Zsaturating-float-casts, which will cause all float to integer casts have "saturating" behavior where if it's out of bounds it's clamped to the nearest bound. A call for benchmarking of this change went out awhile ago. Results, while positive in many projects, are quite negative for some projects and indicates that we're not done here.

The next steps are figuring out how to recover performance for these cases:

• One option is to take today's as cast behavior (which is UB in some cases) and add unsafe functions for the relevant types and such.
• Another is to wait for LLVM to add a freeze concept which means that we get a garbage bit pattern, but it's at least not UB
• Another is to implement casts via inline assembly in LLVM IR, as the current codegen is not heavily optimized.

Old status

UPDATE (by @nikomatsakis): After much discussion, we've got the rudiments of a plan for how to address this problem. But we need some help with actually investigating the performance impact and working out the final details!

---

ORIGINAL ISSUE FOLLOWS:

If the value cannot fit in ty2, the results are undefined.

1.04E+17 as u8

[brson]

Nominating

[pnkfelix]

accepted for P-high, same reasoning as #10183

[pcwalton]

I don't think this is backwards incompatible at a language level. It will not cause code that was working OK to stop working. Nominating.

[pnkfelix]

changing to P-high, same reasoning as #10183

[nrc]

How do we propose to solve this and #10185? Since whether behaviour is defined or not depends on the dynamic value of the number being cast, it seems the only solution is to insert dynamic checks. We seem to agree we do not want to do that for arithmetic overflow, are we happy to do it for cast overflow?

[pcwalton]

We could add an intrinsic to LLVM that performs a "safe conversion". @zwarich may have other ideas.

[zwarich]

AFAIK the only solution at the moment is to use the target-specific intrinsics. That's what JavaScriptCore does, at least according to someone I asked.

[pcwalton]

Oh, that's easy enough then.

[nrc]

ping @pnkfelix is this covered by the new overflow checking stuff?

[bluss]

These casts are not checked by rustc with debug assertions.

[Aatch]

I'm happy to handle this, but I need a concrete solution. I personally think that it should be checked along with overflowing integer arithmetic, as it's a very similar issue. I don't really mind what we do though.

Note that this issue is currently causing an ICE when used in certain constant expressions.

[bluss]

This allows violating memory safety in safe rust, example from this forum post:

Undefs, huh? Undefs are fun. They tend to propagate. After a few minutes of wrangling..

#[inline(never)]
pub fn f(ary: &[u8; 5]) -> &[u8] {
    let idx = 1e100f64 as usize;
    &ary[idx..]
}

fn main() {
    println!("{}", f(&[1; 5])[0xdeadbeef]);
}

segfaults on my system (latest nightly) with -O.

[steveklabnik]

Marking with I-unsound given the violation of memory safety in safe rust.

[steveklabnik]

@bluss , this does not segfualt for me, just gives an assertion error. untagging since i was the one who added it

[steveklabnik]

Sigh, I forgot the -O, re-tagging.

[nagisa]

re-nominating for P-high. Apparently this was at some point P-high but got lower over time. This seems pretty important for correctness.

EDIT: didn’t react to triage comment, adding label manually.

[nikomatsakis]

It seems like the precedent from the overflow stuff (e.g. for shifting) is to just settle on some behavior. Java seems to produce the result modulo the range, which seems not unreasonable; I'm not sure just what kind of LLVM code we'd need to handle that.

[bstrie]

@kennytm Did we expect LLVM 6 to change something? Are they discussing a particular enhancement that would benefit this use case? If so, what's the ticket number?

[shepmaster]

@insanitybit It... appears to still be open...?

[insanitybit]

Welp, no clue what I was looking at. Thanks!

[nagisa]

@rkruppe didn't we ensure that float to int casts are no longer UB in LLVM (by changing docs)? On Jul 20, 2018 4:31 AM, "Colin" <notifications@github.com> wrote: Welp, no clue what I was looking at. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10184 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0v3rJHhZMD7Kv7RC8xkGOiIhkGB1ks5uITMHgaJpZM4BJ45C> .

[SimonSapin]

@nagisa Maybe you’re thinking of f32::from_bits(v: u32) -> f32 (and similarly f64)? It used to do some normalization of NaNs but now is just transmute.

This issue is about as conversions which try to approximate the numerical value.

[rkruppe]

@nagisa You might be thinking of float->float casts, see #15536 and rust-lang-nursery/nomicon#65.

[nagisa]

Ah, yes, that was float to float.

…

On Fri, Jul 20, 2018, 12:24 Robin Kruppe ***@***.***> wrote: @nagisa <https://github.com/nagisa> You might be thinking of float->float casts, see #15536 <#15536> and rust-lang-nursery/nomicon#65 <rust-lang-nursery/nomicon#65>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10184 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AApc0gA24Hz8ndnYhRXCyacd3HdUSZjYks5uIaHegaJpZM4BJ45C> .

[bstrie]

LLVM 7 release notes mention something:

Optimization of floating-point casts is improved. This may cause surprising results for code that is relying on the undefined behavior of overflowing casts. The optimization can be disabled by specifying a function attribute: "strict-float-cast-overflow"="false". This attribute may be created by the clang option -fno-strict-float-cast-overflow. Code sanitizers can be used to detect affected patterns. The clang option for detecting this problem alone is -fsanitize=float-cast-overflow:

Does that have any bearing on this issue?

[retep998]

We shouldn't care what LLVM does for overflowing casts, as long as it isn't unsafe undefined behavior. The result can be garbage as long as it can't cause unsound behavior.

[rkruppe]

Does that have any bearing on this issue?

Not really. The UB did not change, LLVM got even more aggressive about exploiting it, which makes it easier to be affected by it in practice, but the soundness issue is unchanged. In particular, the new attribute does not remove the UB or affect any optimizations that existed before LLVM 7.

[alexcrichton]

@rkruppe out of curiosity, has this sort of fallen by the wayside? It seems like https://internals.rust-lang.org/t/help-us-benchmark-saturating-float-casts/6231/14 went well enough and the implementation hasn't had too many bugs. It seems that a slight performance regression was always expected, but to compile correctly seems like a worthwhile tradeoff.

Is this just waiting to be pushed across the finish line? Or are there other known blockers?

[rkruppe]

Mostly I've been distracted / busy with other things, but a x0.82 regression in RBG JPEG encoding seems more than "slight", a rather bitter pill to swallow (although it's reassuring that other kinds of workload don't seem affected). It's not severe enough that I would object to turning saturation on by default, but enough that I'm hesitant to push for it myself before we've tried the "also provide a conversion function that's faster than saturation but may generate (safe) garbage" option discussed before. I haven't gotten to that, and apparently nobody else has either, so this has fallen by the wayside.

[alexcrichton]

Ok cool thanks for the update @rkruppe! I'm curious though if there's actually an implementation of the safe garbage option? I could imagine us easily providing something like unsafe fn i32::unchecked_from_f32(...) and such, but it sounds like you're thinking that should be a safe function. Is that possible with LLVM today?

[rkruppe]

There's no freeze yet but it is possible to use inline assembly to access the target architecture's instruction for converting floats to integers (with a fallback to e.g. saturating as). While this can inhibit some optimizations, it may be good enough to mostly fix the regression in some benchmarks.

An unsafe function that keeps the UB that this issue is about (and is codegen'd in the same way as as is today) is another option, but a much less attractive one, I'd prefer a safe function if it can get the job done.

[sunfishcode]

There's also significant room for improvement in the safe saturating float-to-int sequence. LLVM today doesn't have anything specifically for this, but if inline asm solutions are on the table, it wouldn't be difficult to do something like this:

     cvttsd2si %xmm0, %eax   # x86's cvttsd2si returns 0x80000000 on overflow and invalid cases
     cmp $1, %eax            # a compact way to test whether %eax is equal to 0x80000000
     jno ok
     ...  # slow path: check for and handle overflow and invalid cases
ok:

which should be significantly faster than what rustc currently does.

[alexcrichton]

Ok I just wanted to be sure to clarify, thanks! I figured that inline asm solutions aren't workable as defaults as it'd inhibit other optimizations too much, but I haven't tried out myself. I'd personally prefer that we close this unsound hole by defining some reasonable behavior (like exactly today's saturating casts). If necessary we can always preserve today's fast/unsound implementation as an unsafe function, and in the limit of time given infinite resources we can even drastically improve the default and/or add other specialized conversion functions (like a safe conversion where out of bounds isn't UB but just a garbage bit pattern)

Would others be opposed to such a strategy? Do we think that this isn't important enough to fix in the meantime?

[rkruppe]

I think inline assembly should be tolerable for cvttsd2si (or similar instructions) specifically because that inline asm would not access memory or have side effects, so it's just an opaque black box that can be removed if unused and doesn't inhibit optimizations around it very much, LLVM just can't reason about the internals and result value of the inline asm. That last bit is why I would be skeptical about e.g. using inline asm for the code sequence @sunfishcode suggests for saturation: the checks introduced for saturation can occasionally be removed today if they're redundant, but the branches in an inline asm block can't be simplified.

Would others be opposed to such a strategy? Do we think that this isn't important enough to fix in the meantime?

I do not object to flipping on saturating now and possibly adding alternatives later, I just don't want to be the one who has to drum up the consensus for it and justify it to users whose code got slower 😅

[nikic]

I've started some work to implement intrinsics for saturating float to int casts in LLVM: https://reviews.llvm.org/D54749

If that goes anywhere, it will provide a relatively low-overhead way of getting the saturating semantics.

[AaronM04]

How does one reproduce this undefined behavior? I tried the example in the comment but the result was 255, which seems OK to me:

println!("{}", 1.04E+17 as u8);

[Manishearth]

Undefined behavior can't be reliably observed that way, sometimes it gives you what you expect but in more complex situations breaks down.

In short, the code generation engine (LLVM) we use is allowed to assume that this doesn't happen, and thus it may generate bad code if it ever relies on this assumption.

[lovasoa]

@AaronM04 an example of reproducible undefined behavior was posted on reddit today:

fn main() {
    let a = 360.0f32;
    println!("{}", a as u8);

    let a = 360.0f32 as u8;
    println!("{}", a);

    println!("{}", 360.0f32 as u8);
}

(see playground)

[shepmaster]

I assume that last comment was meant for @AaronM04, in reference to their previous comment.