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
I believe in the bitcode, store ptr %3, ptr %4 and %4 = getelementptr inbounds %struct.ll, ptr %2, i32 0, i32 1 together is enough to infer %3 is also pointing to struct ll, but SVF does not seem to catch that.
@jumormt Could you kindly help me have a look at this issue? I'm a little confused even after single-stepping SVF.
The text was updated successfully, but these errors were encountered:
jumormt
added a commit
to jumormt/SVF-xiao
that referenced
this issue
Apr 22, 2024
Thanks for reporting. Should be fixed via PR #1443. Actually the type inference site for %3 should be %7 = getelementptr inbounds %struct.ll, ptr %6, i32 0, i32 0 because %6 and %3 are aliases.
Hi,
I was trying to play with type inference under SVF using linked list, and found an unexpected result.
Here is a minimal reproducible example:
And (related part of) its PAG is:
So the PAG node ID of the object on heap is 31.
The type inference result for this object is:
which presents the default type
SVFIntegerType
, indicating that type inference does not work correctly.Here is the IR of
main
:I believe in the bitcode,
store ptr %3, ptr %4
and%4 = getelementptr inbounds %struct.ll, ptr %2, i32 0, i32 1
together is enough to infer%3
is also pointing tostruct ll
, but SVF does not seem to catch that.@jumormt Could you kindly help me have a look at this issue? I'm a little confused even after single-stepping SVF.
The text was updated successfully, but these errors were encountered: