Skip to content

Make saturating u128 -> f32 casts the default behavior #45900

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged

Conversation

hanna-kruppe
Copy link
Contributor

@hanna-kruppe hanna-kruppe commented Nov 9, 2017

... 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

@eddyb
Copy link
Member

eddyb commented Nov 9, 2017

LGTM. cc @alexcrichton @nikomatsakis

@hanna-kruppe hanna-kruppe force-pushed the u128-to-f32-saturation-by-default branch from 91ac0fa to 2d5c892 Compare November 9, 2017 23:46
@scottmcm
Copy link
Member

Check compiletest suite=codegen mode=codegen (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
[01:00:12] 
[01:00:12] running 54 tests
[01:00:16] thread 'main' panicked at 'Some tests failed', /checkout/src/tools/compiletest/src/main.rs:329:21
[01:00:16] i...i.ii...i.............i.....ii......i...i..i..i.F..
[01:00:16] failures:
[01:00:16] 
[01:00:16] ---- [codegen] codegen/unchecked-float-casts.rs stdout ----
[01:00:16] 	
[01:00:16] error: verification with 'FileCheck' failed
[01:00:16] status: exit code: 1
[01:00:16] command: "/usr/lib/llvm-3.9/bin/FileCheck" "--input-file" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/unchecked-float-casts.ll" "/checkout/src/test/codegen/unchecked-float-casts.rs"
[01:00:16] stdout:
[01:00:16] ------------------------------------------
[01:00:16] 
[01:00:16] ------------------------------------------
[01:00:16] stderr:
[01:00:16] ------------------------------------------
[01:00:16] /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/unchecked-float-casts.ll:39:7: error: CHECK-NOT: string occurred!
[01:00:16]  %2 = select i1 %0, float 0x7FF0000000000000, float %1
[01:00:16]       ^
[01:00:16] /checkout/src/test/codegen/unchecked-float-casts.rs:63:16: note: CHECK-NOT: pattern specified here
[01:00:16]  // CHECK-NOT: select
[01:00:16]                ^
[01:00:16] 
[01:00:16] ------------------------------------------
[01:00:16] 
[01:00:16] thread '[codegen] codegen/unchecked-float-casts.rs' panicked at 'explicit panic', /checkout/src/tools/compiletest/src/runtest.rs:2499:8

@hanna-kruppe hanna-kruppe force-pushed the u128-to-f32-saturation-by-default branch from 2d5c892 to 4f29b1c Compare November 10, 2017 08:53
@hanna-kruppe
Copy link
Contributor Author

Oh, I forgot all about that test. Fixed 😅

@kennytm kennytm added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Nov 10, 2017
@alexcrichton
Copy link
Member

Nice! r=me but looks like tidy failed:

[00:02:54] tidy error: /checkout/src/test/codegen/unchecked-float-casts.rs:41: tab character

... 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 rust-lang#41799
@hanna-kruppe hanna-kruppe force-pushed the u128-to-f32-saturation-by-default branch from 4f29b1c to 5952441 Compare November 10, 2017 09:12
@kennytm
Copy link
Member

kennytm commented Nov 10, 2017

@bors r=alexcrichton

@bors
Copy link
Collaborator

bors commented Nov 10, 2017

📌 Commit 5952441 has been approved by alexcrichton

@kennytm kennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 10, 2017
@bors
Copy link
Collaborator

bors commented Nov 12, 2017

⌛ Testing commit 5952441 with merge 19e63bd...

bors added a commit that referenced this pull request Nov 12, 2017
…lexcrichton

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
@bors
Copy link
Collaborator

bors commented Nov 12, 2017

☀️ Test successful - status-appveyor, status-travis
Approved by: alexcrichton
Pushing 19e63bd to master...

@bors bors merged commit 5952441 into rust-lang:master Nov 12, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Casting u128::MAX to f32 is undefined
6 participants