| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296895
|
| |
|
|
|
|
|
|
| |
multiple constraint managers"
This reverts commit ea36f1406e1f36bf456c3f3929839b024128e468.
llvm-svn: 296841
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296837
|
| |
|
|
|
|
|
|
| |
multiple constraint managers"
This reverts commit f93343c099fff646a2314cc7f4925833708298b1.
llvm-svn: 296836
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296835
|
| |
|
|
|
|
|
|
| |
multiple constraint managers"
This reverts commit 1b28d0b10e1c8feccb971abb6ef7a18bee589830.
llvm-svn: 296422
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
constraint managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296414
|
| |
|
|
|
|
|
|
| |
constraint managers"
This reverts commit 8e7780b9e59ddaad1800baf533058d2c064d4787.
llvm-svn: 296317
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
managers
Summary: Replace calls to %clang/%clang_cc1 with %clang_analyze_cc1 when invoking static analyzer, and perform runtime substitution to select the appropriate constraint manager, per D28952.
Reviewers: xazax.hun, NoQ, zaks.anna, dcoughlin
Subscribers: mgorny, rgov, mikhail.ramalho, a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D30373
llvm-svn: 296312
|
| |
|
|
|
|
| |
It was not the cause of the build bot failure.
llvm-svn: 251702
|
| |
|
|
|
|
|
|
| |
Seems to be causing clang-cmake-mips build bot to fail (timeout)
http://lab.llvm.org:8011/builders/clang-cmake-mips/builds/10299
llvm-svn: 251697
|
|
|
Summary:
Dear All,
We have been looking at the following problem, where any code after the constant bound loop is not analyzed because of the limit on how many times the same block is visited, as described in bugzillas #7638 and #23438. This problem is of interest to us because we have identified significant bugs that the checkers are not locating. We have been discussing a solution involving ranges as a longer term project, but I would like to propose a patch to improve the current implementation.
Example issue:
```
for (int i = 0; i < 1000; ++i) {...something...}
int *p = 0;
*p = 0xDEADBEEF;
```
The proposal is to go through the first and last iterations of the loop. The patch creates an exploded node for the approximate last iteration of constant bound loops, before the max loop limit / block visit limit is reached. It does this by identifying the variable in the loop condition and finding the value which is “one away” from the loop being false. For example, if the condition is (x < 10), then an exploded node is created where the value of x is 9. Evaluating the loop body with x = 9 will then result in the analysis continuing after the loop, providing x is incremented.
The patch passes all the tests, with some modifications to coverage.c, in order to make the ‘function_which_gives_up’ continue to give up, since the changes allowed the analysis to progress past the loop.
This patch does introduce possible false positives, as a result of not knowing the state of variables which might be modified in the loop. I believe that, as a user, I would rather have false positives after loops than do no analysis at all. I understand this may not be the common opinion and am interested in hearing your views. There are also issues regarding break statements, which are not considered. A more advanced implementation of this approach might be able to consider other conditions in the loop, which would allow paths leading to breaks to be analyzed.
Lastly, I have performed a study on large code bases and I think there is little benefit in having “max-loop” default to 4 with the patch. For variable bound loops this tends to result in duplicated analysis after the loop, and it makes little difference to any constant bound loop which will do more than a few iterations. It might be beneficial to lower the default to 2, especially for the shallow analysis setting.
Please let me know your opinions on this approach to processing constant bound loops and the patch itself.
Regards,
Sean Eveson
SN Systems - Sony Computer Entertainment Group
Reviewers: jordan_rose, krememek, xazax.hun, zaks.anna, dcoughlin
Subscribers: krememek, xazax.hun, cfe-commits
Differential Revision: http://reviews.llvm.org/D12358
llvm-svn: 251621
|
