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

Re-consider exp.volatiles_are_top #810

Open
michael-schwarz opened this issue Aug 2, 2022 · 3 comments
Open

Re-consider exp.volatiles_are_top #810

michael-schwarz opened this issue Aug 2, 2022 · 3 comments
Labels
cleanup Refactoring, clean-up precision relational Relational analyses (Apron, affeq, lin2var) unsound

Comments

@michael-schwarz
Copy link
Member

We currently enable this everywhere, which leads to volatile and extern variables always having the value T.

While this of course safe and makes sense when analyzing e.g. drivers, it may be unnecessarily imprecise to consider all volatiles T in other settings. We should, e.g., investigate if this can be turned off for sv-comp at least.

@sim642
Copy link
Member

sim642 commented Aug 3, 2022

It would also be worth checking if sv-benchmarks even use these. There shouldn't be any externs since the programs are supposed to be closed. There might be volatiles though.

The other thing to review is how well exp.volatiles_are_top is followed at all. AFAIK Apron analysis doesn't even consider that, but if we have such an option, then the support should be consistent.

@michael-schwarz
Copy link
Member Author

There are a few places in sv-comp where volatiles are used, though it does not seem like there are sufficient numbers to justify doing this for this year's svcomp.

@michael-schwarz michael-schwarz removed this from the SV-COMP 2023 milestone Nov 18, 2022
@sim642 sim642 changed the title Re-consider exp.volatiles_are_top as default Re-consider exp.volatiles_are_top Dec 20, 2024
@sim642 sim642 added cleanup Refactoring, clean-up unsound relational Relational analyses (Apron, affeq, lin2var) labels Dec 20, 2024
@sim642
Copy link
Member

sim642 commented Dec 20, 2024

As noted in #1552 (comment), only the none base privatization even considers the option (for locals). And for some reason during writing, not reading.

So there's a lot to reconsider here besides just the default. Other privatizations and other (relational) value analyses don't use this option and thus behave differently. The option probably makes sense for embedded/driver code, at least for volatile globals, but all value analyses should then actually respect it, otherwise they will still return more precise values.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cleanup Refactoring, clean-up precision relational Relational analyses (Apron, affeq, lin2var) unsound
Projects
None yet
Development

No branches or pull requests

2 participants