-
Notifications
You must be signed in to change notification settings - Fork 13
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
Issue in constraint generation enforcing reads-from #39
Comments
Although, adding this constraint causes many of the existing tests to fail, so need to look into this a little more. |
Ok, needed to add a couple checks to deal with cases where write/read values are unconstrained. The full condition now is:
All tests pass when generated using this condition. |
I'm running into one other potentially buggy test outcome. Given this test:
A solution is found where Adding another constraint when generating
|
If I have the following simple test, which checks whether a load returns a previous store, the test fails (a satisfiable solution is found).
Looking at the counterexample generated, the issue appears to be that Alloy happily puts a reads-from relation between the two instructions, despite 2 not being the value written previously. When putting
ld.sc0 c = 0
, the test passes, because a constraint of the formE1 in X.RFINIT
is correctly generated. The issue exists for both atomic/non-atomic instructions.I don't think the problem is with the model, it looks like adding a
not in
constraint torf
fixes the problem, which can be done inlitmus.cpp
by adding the following code to lines 534-547:The text was updated successfully, but these errors were encountered: