-
Notifications
You must be signed in to change notification settings - Fork 76
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
Make threadflag/thread analysis path-sensitive #148
Comments
As I said in #155, there's an experimental fix in |
Key parts of the experiment have now been cherry-picked to |
Since the implementation parts already reached |
The thread join support from PR #137 didn't improve our results on SV-COMP's NoDataRace benchmarks as much as expected. At least some of them create and join threads conditionally. This currently renders the added thread join support useless because joins in the thread analyses lose the necessary precision. Making threadflag and maybe even thread analysis path-sensitive would help with that.
I made a quick experiment but turns out this is problematic and cannot currently easily be done. The issue is the
S.context d
call here:analyzer/src/framework/constraints.ml
Lines 566 to 579 in 9fd3ccc
If
d
is a path-sensitivity domain set that happens to contain more than one path, thenS.context
fails because it can just return a single context. It might be necessary to rework this mechanism to be more like our previous function call mechanism whereenter
returns a list, not a single element, which is then handled inFromSpec
to applyS.context
per-element.(That in itself is a weird mechanism because the path-sensitivity handling isn't localized to the corresponding lifter but throughout the analysis specification hierarchy.)
I have my doubts about being able to achieve this by SV-COMP 2021.
The text was updated successfully, but these errors were encountered: