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

Spurious failure on leading_zeros #886

Closed
zhassan-aws opened this issue Mar 4, 2022 · 4 comments · Fixed by #965
Closed

Spurious failure on leading_zeros #886

zhassan-aws opened this issue Mar 4, 2022 · 4 comments · Fixed by #965
Labels
[C] Bug This is a bug. Something isn't working.

Comments

@zhassan-aws
Copy link
Contributor

This failure only occurs with the next, not-yet-integrated version of CBMC (5.52.0). This may be related to diffblue/cbmc#6703.

I tried this code:

fn main() {
    let x: u64 = 0;
    let _ = x.leading_zeros();
}

using the following command line invocation:

kani test.rs

with Kani version: 53f15955016 but with CBMC 5.52.0

I expected to see this happen: Verification successful

Instead, this happened: Verification failed:

CBMC 5.52.0 (cbmc-5.52.0)
CBMC version 5.52.0 (cbmc-5.52.0) 64-bit x86_64 linux
<snip>
Check 2: bit_count.1
         - Status: FAILURE
         - Description: "count leading zeros is undefined for value zero in __builtin_clz(var_3)"

Check 3: core::num::<impl u64>::leading_zeros.overflow.1
         - Status: SUCCESS
         - Description: "arithmetic overflow on unsigned to unsigned type conversion in (unsigned int)var_2"
<snip>

SUMMARY: 
 ** 1 of 4 failed
Failed Checks: count leading zeros is undefined for value zero in __builtin_clz(var_3)

VERIFICATION:- FAILED

Running it with rustc produces no failures.

@zhassan-aws zhassan-aws added the [C] Bug This is a bug. Something isn't working. label Mar 4, 2022
@tautschnig
Copy link
Member

I'm afraid that I broke this in diffblue/cbmc@4d4f9e7d182643f8. Fixing PR forthcoming.

tautschnig added a commit to tautschnig/cbmc that referenced this issue Mar 4, 2022
The cleanup of 4d4f9e7 (PR diffblue#6684) made bounds checking of these bit
count expressions unconditional. This did not affect any input coming
from the C front-end, but became apparent with the Rust front-end as
documented in model-checking/kani#886.

This commit restores conditional bounds checking, but now actually uses
the proper expression API rather than the low-level hack.
@tautschnig
Copy link
Member

diffblue/cbmc#6708 addresses this problem.

tautschnig added a commit to tautschnig/cbmc that referenced this issue Mar 8, 2022
The cleanup of 4d4f9e7 (PR diffblue#6684) made bounds checking of these bit
count expressions unconditional. This did not affect any input coming
from the C front-end, but became apparent with the Rust front-end as
documented in model-checking/kani#886.

This commit restores conditional bounds checking, but now actually uses
the proper expression API rather than the low-level hack.
@tautschnig
Copy link
Member

This is now merged in CBMC and will be part of the 5.53.0 release (due to be published 2022-03-17).

@adpaco-aws
Copy link
Contributor

Opened #928 to disable the test since it was failing after CBMC was updated in homebrew. I will revisit this as part of #727 and re-enable the test once 5.53.0 is online.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[C] Bug This is a bug. Something isn't working.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants