-
Notifications
You must be signed in to change notification settings - Fork 97
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
Upgrade to CBMC 5.69.1 (with fixes) #1811
Conversation
Return `VoidUnit` (type `struct Unit`) instead in those functions
51c2af0
to
4815cd5
Compare
@@ -286,6 +289,7 @@ impl Type { | |||
CInteger(CIntType::Bool) => Some(mm.bool_width), | |||
CInteger(CIntType::Char) => Some(mm.char_width), | |||
CInteger(CIntType::Int) => Some(mm.int_width), | |||
Integer => Some(mm.int_width), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is unbounded, it doesn’t have a bitwidth.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done. Thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, do you think we should return None
or just Some(x)
where x is a large number?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe we can have an "infinite" token? But Some(x)
is semantically wrong for all x
@@ -58,7 +65,7 @@ pub fn machine_model_symbols(mm: &MachineModel) -> Vec<Symbol> { | |||
), | |||
int_constant("__CPROVER_architecture_wchar_t_width", mm.wchar_t_width), | |||
int_constant("__CPROVER_architecture_word_size", mm.word_size), | |||
int_constant("__CPROVER_rounding_mode", mm.rounding_mode), | |||
int_constant_c_int("__CPROVER_rounding_mode", mm.rounding_mode), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seriously? There is one remaining outlier? Is there an issue open to CBMC about that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couldn't find one, so I opened diffblue/cbmc#7282 (and pasted the issue there)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll comment on the CBMC issue, but indeed rounding mode is different.
// But for some reason, not pushing it causes a CBMC invariant violation | ||
// since version 5.68.0. | ||
// <https://github.com/model-checking/kani/issues/1810> | ||
args.push("--slice-formula".into()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this mess with concrete playback?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs more investigation.
My understanding was that using --slice-formula
with concrete playback may remove calls to kani::any()
from the trace, which doesn't allow us to provide a counter-example (in that case, we just report a test couldn't be generated). But all tests we have for concrete playback and --visualize
pass if we use --slice-formula
.
library/kani/kani_lib.c
Outdated
// Note: the Kani compiler changes `void` return types to the empty tuple `()` | ||
// AKA `VoidUnit`. Because of that, we need to declare its type `struct Unit` | ||
// and the extern instance `VoidUnit` here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is an accurate description. Rust ()
is not the same thing as void, and __rust_dealloc
is extern Rust not extern C https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/src/alloc/alloc.rs.html#37
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've changed it to the same comment we use in the Kani compiler's typ.rs
module:
/// Mapping unit to `void` works for functions with no return type but not for
/// variables with type unit. We treat both uniformly by declaring an empty
/// struct type: `struct Unit {}` and a global variable `struct Unit VoidUnit`
/// returned by all void functions (both declared by the Kani compiler).
High-level note: you might consider upgrading to 5.69.1 right away, which will be out later on today (diffblue/cbmc#7283). |
Tried now, but |
Please retry, should just be a matter of timing. |
85eb7a4
to
38e5f23
Compare
@@ -48,7 +55,11 @@ struct Foo2 { | |||
|
|||
uint32_t S = 12; | |||
|
|||
void update_static() { S++; } | |||
struct Unit update_static() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is something that ought to work once C-FFI is in place. We should have comments and a tracking ticket explaining that this is a workaround we want to remove
This reverts commit 3007e84.
Description of changes:
NOTE: This PR initially upgraded CBMC to v5.68.0, but it was actually upgraded to v5.69.1 as part of the review process. Unfortunately, the commit was added without first editing the title.
Upgrades CBMC to v5.69.1 and changes Kani so that it conforms with the latest changes in CBMC:
integer
type where appropriate (also adds required support to generateinteger
ireps). This change was forced by CBMC (see Updating to latest CBMC version requires update to architecture strings #1779)void
return types so they use typestruct Unit
instead. This is necessary because of stricter type-checking in CBMC (likely caused by Fix linking in case of function type conflict diffblue/cbmc#6547)--slice-formula
, even in the cases where we didn't (opened Not using--slice-formula
causes invariant violation in CBMC #1810 for debugging).cargo-kani
suite. This was the last test failing, but it run its own compilation process so it was dubious. Moving intocargo-kani
showed no issues.Resolved issues:
Resolves #1779
Testing:
How is this change tested? Existing egression.
Is this a refactor change? No.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.