-
Notifications
You must be signed in to change notification settings - Fork 440
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
Higher optimization level leads to broken value flow in virtual functions #1312
Comments
Thanks for reporting this, could you upload the bc files before and after the optimisation? |
Here are the bitcodes compiled with both O0 and O3. |
May I ask if there is any update on this issue? @yuleisui |
@xudon9 could you have a look at this issue? |
We have received several issues with virtual functions. We are reviewing related parts of C++ feature handling. It might take a while before all the problems get solved. Thanks. |
Though it's a bit late, I still want to add a tiny finding. The SVFG remains a consistent value flow if FYI, all the results above are generated under |
For anymore who might concern, this issue is resolved possibly due to #1369. Below is the SVFG on O3-optimized bitcode, from which we can clearly see the consistent value-flow now (two read arrows). Make sure to use LLVM 16 otherwise latest SVF would fail on:
|
Hi, I encounter some problems when playing with virtual functions under SVF. Below is a minimal reproducible example:
Obviously,
a
frommain
is passed throughmyClass::foo(int *a)
, and eventually modified inmyClass::foo(int *a, int b)
. This is a consistent value flow, and is captured by SVF when compiled without optimization, as shown in two red arrows in the graph below.However, when compiled with O3, SVFG is as follows:
There is only one red arrow, indicating the value flow from
main
tomyClass::foo(int *a)
.a
inmyClass::foo(int *a, int b)
does not have any source in this case. I was expecting to see a red arrow connecting node 58 and 62, but there is not. Is it an expected behavior?FYI, both bitcodes are compiled under clang++ 14.0.0.
Thanks for your time and happy new year!
The text was updated successfully, but these errors were encountered: