Skip to content
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

Miri/CTFE: properly treat overflow in (signed) division/rem as UB #94512

Merged
merged 2 commits into from
Mar 3, 2022

Conversation

RalfJung
Copy link
Member

@RalfJung RalfJung commented Mar 2, 2022

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR Div/Rem directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? @oli-obk

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Mar 2, 2022
@rust-highfive
Copy link
Collaborator

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

Some changes occured to the CTFE / Miri engine

cc @rust-lang/miri

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 2, 2022
@rust-log-analyzer

This comment has been minimized.

// see https://github.com/rust-lang/rust/pull/94512.
const _: () = {
assert!(i32::MIN.wrapping_div(-1) == i32::MIN);
assert!(i32::MIN.wrapping_rem(-1) == 0);
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Turns out wrapping_div/rem actually does distinguish between div-by-0 and overflow, but LLVM does not (both are UB). For a second I thought wrapping_div relies on the old behavior of the interpreter, but turns out that function actually explicitly checks for this case and avoids even calling the MIR operator. So we are good.

But this is subtle enough that it warrants a specific test.

@oli-obk
Copy link
Contributor

oli-obk commented Mar 2, 2022

@bors r+ rollup

@bors
Copy link
Contributor

bors commented Mar 2, 2022

📌 Commit 6739299 has been approved by oli-obk

@bors bors 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 Mar 2, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 2, 2022
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? `@oli-obk`
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 2, 2022
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? ``@oli-obk``
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this pull request Mar 2, 2022
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? ```@oli-obk```
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 2, 2022
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? ````@oli-obk````
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 2, 2022
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? `````@oli-obk`````
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 2, 2022
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? ``````@oli-obk``````
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Mar 2, 2022
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? ```````@oli-obk```````
@Dylan-DPC
Copy link
Member

failed in rollup

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 3, 2022
@RalfJung
Copy link
Member Author

RalfJung commented Mar 3, 2022

@bors rollup=never

The rust-log output is misleading, that is Miri failing which is fine. The actual issue (I think) is

     Running tests\compile-test.rs (build\x86_64-pc-windows-msvc\stage2-tools\x86_64-pc-windows-msvc\release\deps\compile_test-93a03ccdd9aec39c.exe)

[...]

failures:
    [ui] ui\modulo_one.rs

test result: FAILED. 682 passed; 1 failed; 9 ignored; 0 measured; 0 filtered out; finished in 16.33s

Sadly this doesn't even say which tools's test suite this is a part of.^^ But I guess it must be clippy?

@RalfJung
Copy link
Member Author

RalfJung commented Mar 3, 2022

I updated the stderr file by hand (since blessing clippy does not seem easily possible) -- hopefully that means the PR runner will now run Clippy tests.

@Dylan-DPC
Copy link
Member

@bors r=oli-obk

@bors
Copy link
Contributor

bors commented Mar 3, 2022

📌 Commit 24fc115 has been approved by oli-obk

@bors bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 3, 2022
@RalfJung
Copy link
Member Author

RalfJung commented Mar 3, 2022

@bors r-

I'd prefer to first see if PR CI is green.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 3, 2022
@Dylan-DPC
Copy link
Member

ah oops :D

@oli-obk
Copy link
Contributor

oli-obk commented Mar 3, 2022

@bors r+

@bors
Copy link
Contributor

bors commented Mar 3, 2022

📌 Commit 24fc115 has been approved by oli-obk

@bors bors 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-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 3, 2022
@bors
Copy link
Contributor

bors commented Mar 3, 2022

⌛ Testing commit 24fc115 with merge 4566094...

@bors
Copy link
Contributor

bors commented Mar 3, 2022

☀️ Test successful - checks-actions
Approved by: oli-obk
Pushing 4566094 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Mar 3, 2022
@bors bors merged commit 4566094 into rust-lang:master Mar 3, 2022
@rustbot rustbot added this to the 1.61.0 milestone Mar 3, 2022
@rust-highfive
Copy link
Collaborator

📣 Toolstate changed by #94512!

Tested on commit 4566094.
Direct link to PR: #94512

💔 miri on windows: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb).

rust-highfive added a commit to rust-lang-nursery/rust-toolstate that referenced this pull request Mar 3, 2022
Tested on commit rust-lang/rust@4566094.
Direct link to PR: <rust-lang/rust#94512>

💔 miri on windows: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb).
💔 miri on linux: test-pass → test-fail (cc @oli-obk @RalfJung @eddyb).
bors added a commit to rust-lang/miri that referenced this pull request Mar 3, 2022
adjust for div/rem overflow being UB

This is the Miri side of rust-lang/rust#94512. Just some error messages change.
@rust-timer
Copy link
Collaborator

Finished benchmarking commit (4566094): comparison url.

Summary: This benchmark run did not return any relevant results. 3 results were found to be statistically significant but too small to be relevant.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

@RalfJung RalfJung deleted the sdiv-ub branch March 6, 2022 00:23
flip1995 pushed a commit to flip1995/rust that referenced this pull request Mar 14, 2022
Miri/CTFE: properly treat overflow in (signed) division/rem as UB

To my surprise, it looks like LLVM treats overflow of signed div/rem as UB. From what I can tell, MIR `Div`/`Rem` directly lowers to the corresponding LLVM operation, so to make that correct we also have to consider these overflows UB in the CTFE/Miri interpreter engine.

r? `@oli-obk`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants