-
Notifications
You must be signed in to change notification settings - Fork 11
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
Resetting WP Interpolant for assertion failure/memory error #400
Comments
Made this change in commit 9f3e629. |
should we close this issue? |
I wanted to discuss a few things regarding this change. With this change, we are not able to subsume any other path with the same assertion violation. We are expecting this behavior only. Am I correct? |
Comment from Arpi:
|
This is intended behaviour, one of the cases emits all occurances of an error and the other emits only the first occurance of an error. We have a command-line option which toggles this off/on on deletion. We can use the same command-line option here too. |
Are you suggesting for this option -emit-all-errors-in-same-path? |
In my opinion this commit 9f3e629 will increase a bit of run-time by ignoring the subsumption of a error path starting from the same program point for which earlier a error is reported. Can we disable this commit for our test-comp submission? |
sure. |
I am disabling this commit and let you know once this branch is ready for the MR. |
I have made the changes in commit 1d5f8d3. |
At present, the wp-interpolant is set as true even when we hit an error/failure for a node.
In the last to last meeting, we decided to reset the value of the wp-interpolant to false whenever reach a failure.
For to achieve this, in
TxTree::remove()
function, beforeTxSubsumptionTable::insert(node->getProgramPoint(),node->entryCallHistory, entry);
, I have reset the wp-interpolant value based on the assert failure value of that node.The text was updated successfully, but these errors were encountered: