You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This test would fail due to eval_int of texpr a evaluating for some mysterious reason to top, and then in the next step being incremented by one, causing the overflow in line 6.
This
happens for affeq as well as lin2vareq; it is revealed during the expression conversion that happens for relationalAnalyses in sharedFunctions, since this does some calls to eval_int
happens only for a being a global variable, disappearing for a local a declaration.
Fixing this will make a few no-overflow tasks in sv-comp solvable for lin2vars and affeqs.
A quick dive into what happens during analysis time revealed some interactions with some a#in and a#out that I do not understand yet, but maybe someone wants to lend a hand.
The text was updated successfully, but these errors were encountered:
A quick dive into what happens during analysis time revealed some interactions with some a#in and a#out that I do not understand yet, but maybe someone wants to lend a hand.
My quick guess would be that the overflow handling in relational analyses, which makes those queries, doesn't correctly handle those temporary variables and does queries on a#in, which other analyses know nothing about.
A quick dive into what happens during analysis time revealed some interactions with some a#in and a#out that I do not understand yet, but maybe someone wants to lend a hand.
My quick guess would be that the overflow handling in relational analyses, which makes those queries, doesn't correctly handle those temporary variables and does queries on a#in, which other analyses know nothing about.
That is probably what is happening - the resulting value "top" for an eval_int on a#in etc. is intended, then?
There might be some discussion somewhere, but the clean solution would be to move overflow warning generation out of int domain operators themselves and have the new MaySignedOverflow query be used explicitly to generate these warnings.
Int domain operators already return overflow_info in addition to the result, so this could simply be used by MaySignedOverflow.
The following issue popped up when doing intensive sv-comp tests:
This test would fail due to eval_int of texpr a evaluating for some mysterious reason to top, and then in the next step being incremented by one, causing the overflow in line 6.
This
Fixing this will make a few no-overflow tasks in sv-comp solvable for lin2vars and affeqs.
A quick dive into what happens during analysis time revealed some interactions with some a#in and a#out that I do not understand yet, but maybe someone wants to lend a hand.
The text was updated successfully, but these errors were encountered: