-
Notifications
You must be signed in to change notification settings - Fork 5
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
Erroneous CFA generation vol 2 #46
Comments
What is the output without optimizations ( |
With passing both
|
For a smaller example, the generated code is correct (also when using if instead of while). I tried it with
The generated excerpt:
|
This is a PHI assignment. Are you confident that the assignment on the other incoming branch does not make this code correct? Does the verification produce an incorrect result (either with theta or the BMC algorithm)? |
The verification produces an incorrect result for the problem in the first comment with In the example the error location should not be reachable, however,
|
Can you run |
I looked at the generated automata and the original LLVM module. The generated code seems to be a faithful representation of the code coming from LLVM, which also looks correct (and BMC provides a correct result on it).
@as3810t Unless you are able to pinpoint the semantic difference yourself, I would recommend to look into the backend algorithm executed by theta. |
@as3810t I think you sent the wrong file. The interesting files should be .gcd.dot and .gcd.loop.dot in this context. Oh, I think gazer-cfa does not exactly work like that... :/ Sorry |
I found the following cases, where I think the outputted CFA is semantically different than the input C program. In each case, I generated the CFA with
All cases have in common:
|
Thanks for the detailed report. Gazer's CFA assumes some kind of SSA-form, but uses more assumptions right now, I think. (A strict SSA would need Phi nodes. Now the only assumption is (should be) that one loop or one function assigns only one value per path for a given variable) This is handled by "PhiInputs". At the start of the loop, when a variable is changed in the loop. There could be two assignments where the value could come from: from before the loop or inside the loop in a previous iteration. So gcd_loop(a,b) returns gcd_loop(b,a%b). I think the problem lies in the phi input assignments affecting each other (when building up these in Theta). Input assignments are part of the inlining process when instead of "calling", one assigns the input variables with the given value. This could be in some inlining mechanism or in RecursiveToCyclicCfa.cpp lines 192- and 257- |
The solution could be a bit hard. Assigning in two stages ( |
For input problem:
GAZER generates an erroneous CFA with command (that uses GAZER version in #39 ):
The slip-up happens during the translation of the variable swapping
The corresponding generated CFA is:
Which corresponds to:
The text was updated successfully, but these errors were encountered: