Author: seaneveson
Date: Mon Jan 8 07:46:18 2018
New Revision: 322000
URL: http://llvm.org/viewvc/llvm-project?rev=322000=rev
Log:
Fix test added in r321992 failing on some buildbots (again), test requires x86.
Modified:
cfe/trunk/test/CodeGen/stack-size-section.c
Modified:
Author: seaneveson
Date: Mon Jan 8 06:43:28 2018
New Revision: 321995
URL: http://llvm.org/viewvc/llvm-project?rev=321995=rev
Log:
Fix test added in r321992 failing on some buildbots.
Modified:
cfe/trunk/test/CodeGen/stack-size-section.c
Modified:
Author: seaneveson
Date: Mon Jan 8 05:42:26 2018
New Revision: 321992
URL: http://llvm.org/viewvc/llvm-project?rev=321992=rev
Log:
[Driver] Add flag enabling the function stack size section that was added in
r319430
Adds the -fstack-size-section flag to enable the .stack_sizes section. The
Hi,
It looks like the test is still failing on one of the Windows build bots:
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015
>From looking at the test locally it seems the problem is when you do `//
RUN: not env...`. The env command doesn't get handled by llvm-lit.py,
because it
seaneveson added inline comments.
Comment at: lib/StaticAnalyzer/Core/MemRegion.cpp:334
void BlockCodeRegion::Profile(llvm::FoldingSetNodeID& ID) const {
+ locTy->getTypePtr()->isBlockPointerType();
BlockCodeRegion::ProfileRegion(ID, BD, locTy, AC, superRegion);
seaneveson added a subscriber: seaneveson.
seaneveson closed this revision.
seaneveson added a comment.
Committed: http://reviews.llvm.org/rL270849
http://reviews.llvm.org/D19866
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
Author: seaneveson
Date: Thu May 26 09:02:17 2016
New Revision: 270849
URL: http://llvm.org/viewvc/llvm-project?rev=270849=rev
Log:
[Analyzer] Correct stack address escape diagnostic
Summary:
Leaking a stack address via a static variable refers to it in the diagnostic as
a 'global'. This patch
Author: seaneveson
Date: Wed Jan 6 04:03:58 2016
New Revision: 256926
URL: http://llvm.org/viewvc/llvm-project?rev=256926=rev
Log:
[Analyzer] Change the default SA checkers for PS4
Summary: This patch removes security.*, unix.API and unix.Vfork from the
default checkers for PS4.
Reviewers:
seaneveson updated this revision to Diff 44098.
seaneveson marked an inline comment as done.
seaneveson added a comment.
Removing old "experimental" comment
http://reviews.llvm.org/D15888
Files:
lib/Driver/Tools.cpp
test/Driver/ps4-analyzer-defaults.cpp
Index:
seaneveson added a comment.
In http://reviews.llvm.org/D14919#296597, @o.gyorgy wrote:
> I did not create a test checker for the NormalizeLine error in the patch.
> Should I add a test checker for this?
I was wondering what sort of source code causes the crash, but I do think it
would be
seaneveson added a comment.
> If you have multiple users using a bug suppression system, I would design
> such system using only a single hash version across all users; using a mix
> seems error prone.. Once all of your users upgrade to a version of the
> analyzer where a new hash version is
seaneveson added a comment.
In http://reviews.llvm.org/D10305#286385, @zaks.anna wrote:
> The reason I like names more than the numbers is that we may use different
> solutions for issue hash generation and some users might prefer one over the
> other. It is not necessarily clear which one is
seaneveson added a comment.
In http://reviews.llvm.org/D10305#286119, @xazax.hun wrote:
> A third alternative would be to have both semantic names (containing hash)
> and a number suffix which indicates the ordering.
Yes that would work, but I don't understand the benefit of having the
seaneveson abandoned this revision.
seaneveson added a comment.
Fixed by r252506. Thanks Devin.
http://reviews.llvm.org/D14498
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Author: seaneveson
Date: Tue Nov 10 05:48:55 2015
New Revision: 252599
URL: http://llvm.org/viewvc/llvm-project?rev=252599=rev
Log:
[Analyzer] Fix comments and formatting. NFC.
Modified:
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/LoopWidening.h
seaneveson added a comment.
We are working on tools that use the new hash for bug suppression. There seems
to be no way to predict the names of future hashes. We have products (that will
use the bug identification) that are on a different release schedule to our
clang compiler. These tools
seaneveson added a comment.
Fix an assertion which occurs when getCXXThisVal() returns an Unknown SVal and
the Analyzer tries to get the corresponding memory region.
This assertion was reported in PR25392. The test case from this Bugzilla has
been added.
(Forgot to add cfe-commits when
Author: seaneveson
Date: Fri Oct 30 06:13:07 2015
New Revision: 251697
URL: http://llvm.org/viewvc/llvm-project?rev=251697=rev
Log:
Revert r251621 "[Analyzer] Widening loops which do not exit" (bot failure)
Seems to be causing clang-cmake-mips build bot to fail (timeout)
Author: seaneveson
Date: Fri Oct 30 10:23:57 2015
New Revision: 251702
URL: http://llvm.org/viewvc/llvm-project?rev=251702=rev
Log:
Reapply r251621 "[Analyzer] Widening loops which do not exit"
It was not the cause of the build bot failure.
Added:
seaneveson updated this revision to Diff 38717.
seaneveson added a comment.
Updated to latest revision
http://reviews.llvm.org/D12358
Files:
include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
include/clang/StaticAnalyzer/Core/PathSensitive/LoopWidening.h
This revision was automatically updated to reflect the committed changes.
Closed by commit rL251621: [Analyzer] Widening loops which do not exit
(authored by seaneveson).
Changed prior to commit:
http://reviews.llvm.org/D12358?vs=38717=38718#toc
Repository:
rL LLVM
Author: seaneveson
Date: Thu Oct 29 05:04:41 2015
New Revision: 251621
URL: http://llvm.org/viewvc/llvm-project?rev=251621=rev
Log:
[Analyzer] Widening loops which do not exit
Summary:
Dear All,
We have been looking at the following problem, where any code after the
constant bound loop is not
seaneveson updated this revision to Diff 38519.
seaneveson added a comment.
Removed checking for already exited loops
Addressed Comments
http://reviews.llvm.org/D12358
Files:
include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
include/clang/StaticAnalyzer/Core/PathSensitive/LoopWidening.h
seaneveson marked 5 inline comments as done.
Comment at: test/Analysis/loop-widening.c:160
@@ +159,3 @@
+void variable_bound_exiting_loops_widened(int x) {
+ int i = 0;
+ int t = 1;
The inner loop will now be widened in the first example test, which
seaneveson marked an inline comment as done.
seaneveson added a comment.
Hi Devin,
Sorry it also took me so long to get back to you.
Comment at: include/clang/StaticAnalyzer/Core/AnalyzerOptions.h:266
@@ +265,3 @@
+ /// \sa shouldWidenLoops
+ bool WidenLoops;
+
Author: seaneveson
Date: Fri Oct 16 03:54:23 2015
New Revision: 250500
URL: http://llvm.org/viewvc/llvm-project?rev=250500=rev
Log:
Test commit
Modified:
cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
Modified: cfe/trunk/lib/StaticAnalyzer/Core/CallEvent.cpp
URL:
seaneveson marked 3 inline comments as done.
seaneveson added a comment.
In http://reviews.llvm.org/D12358#266391, @dcoughlin wrote:
> I think this is an acceptable loss of precision because, in general, it is
> unlikely that a concrete-bounded loop will be executed *exactly*
>
seaneveson updated this revision to Diff 37462.
seaneveson added a comment.
Set CausedByPointerEscape to true
Check if the loop has already been exited before widening
Changed tests to use void clang_analyze_eval(int)
Added variable bound loop tests
Added nested loop tests
seaneveson updated this revision to Diff 37084.
seaneveson added a comment.
Updated to latest trunk
Replaced some code with an existing method: ignoreParenBaseCasts()
Could someone commit this for me as I don't have SVN access?
Thank you.
http://reviews.llvm.org/D13099
Files:
seaneveson updated this revision to Diff 36927.
seaneveson added a comment.
Updated to latest trunk.
Added FIXME test for circular reference issue.
http://reviews.llvm.org/D13099
Files:
include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
lib/StaticAnalyzer/Core/CallEvent.cpp
seaneveson updated this revision to Diff 36845.
seaneveson added a comment.
Move PR21606 test into const-method-call.cpp.
Added test for const calls on member objects.
Added tests for inherited const methods.
Changed TK_PreserveContents to be set for the base region. This is so memory is
still
seaneveson marked 4 inline comments as done.
seaneveson added a comment.
There are some issues which haven't been resolved yet:
- There is a loss of precision for loops that need to be executed exactly
maxBlockVisitOnPath times, as the loop body is executed with the widened state
**instead**
seaneveson updated this revision to Diff 36739.
seaneveson added a comment.
Updated to latest revision.
Change patch to widen all loops which do not exit.
Changed to widen on block entrance so the guard condition is accounted for
(thanks for the suggestion).
Updated tests to reflect changes.
seaneveson marked 6 inline comments as done.
seaneveson added a comment.
There is an issue where pointers to the object (this) should cause it to be
invalidated, but don't since TK_PreserveContents has been set.
For example:
class B;
class A {
B b;
const foo();
};
class B {
seaneveson updated this revision to Diff 36604.
seaneveson added a comment.
Removed mutable field from derived class in inheritance test case.
http://reviews.llvm.org/D13099
Files:
include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
lib/StaticAnalyzer/Core/CallEvent.cpp
seaneveson marked an inline comment as done.
seaneveson added a comment.
http://reviews.llvm.org/D13099
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
seaneveson added a comment.
Could you update this patch to the latest trunk please? There's a conflict with
http://reviews.llvm.org/rL248516.
Thanks.
http://reviews.llvm.org/D12993
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
seaneveson added a comment.
My initial approach was for the analyzer to have as much information as
possible after the loop. This means there are cases where the information is
incorrect. Future work would be to reduce these cases.
I believe your preferred approach is to have no inaccuracies
seaneveson added a comment.
I've realized that the patch doesn't handle pointers correctly, since a const
method can modify the memory pointed at by a member. While pointer members
should not be invalidated by const methods (if they are not mutable), the
memory they point to should still be
seaneveson added a comment.
Thank you for looking at the patch and all your comments.
In http://reviews.llvm.org/D13099#252492, @xazax.hun wrote:
> One more note. Do we want to support const_cast for this? A possible way to
> do that is to invalidate this, when a const cast appears in the body
seaneveson updated this revision to Diff 35617.
seaneveson added a comment.
Removed unnecessary call to getCanonical.
Changed if statement checking getting ThisRegion to an assert.
Added code to handle mutable members of base classes.
http://reviews.llvm.org/D13099
Files:
seaneveson added a comment.
Thank you for your comments.
@zaks.anna wrote:
> What do you mean by "approximate"?
I think @dcoughlin gave a perfect example in the following comment:
@dcoughlin wrote:
> This doesn't seem quite right. Consider:
>
> int i;
> for (i = 0; i < 21; i += 3) {}
>
seaneveson created this revision.
seaneveson added a subscriber: cfe-commits.
Dear All,
I would like to propose a patch that prevents the invalidation of ‘this’ when a
method is const; fixing the test case given below, taken from PR 21606
(https://llvm.org/bugs/show_bug.cgi?id=21606).
```
seaneveson updated this revision to Diff 35216.
seaneveson added a comment.
The TK_EntireMemSpace trait is now used when invalidating. The trait was added
in http://reviews.llvm.org/D12993, thank you Devin for that patch.
Updated to the latest trunk.
http://reviews.llvm.org/D12358
Files:
seaneveson added a comment.
In http://reviews.llvm.org/D12358#241631, @cfe-commits wrote:
> Hi Sean,
>
> Ted provided more details off-list. He suspects that the problem is that we
> likely don't add MemSpaceRegions to the worklist because every region is a
> subregion of a MemSpaceRegion, and
seaneveson updated this revision to Diff 34196.
seaneveson added a comment.
I changed the name to min-cfg-size-treat-functions-as-large, thanks for the
suggestion.
If the patch is acceptable can someone commit it for me?
http://reviews.llvm.org/D12406
Files:
seaneveson added a comment.
Ping
http://reviews.llvm.org/D12406
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
seaneveson updated this revision to Diff 33906.
seaneveson added a comment.
Refactored into a new file: LoopWidening.cpp (and LoopWidening.h).
Added an analyzer-config option, which defaults to false:
widen-constant-bound-loops=false
Modified analyzer-config tests to check for the new option.
seaneveson added a comment.
In http://reviews.llvm.org/D12358#237099, @krememek wrote:
> To get the conservative invalidation that Anna suggests (actually, a little
> less conservative), I think you can just pass in a two MemRegions as the
> input to that method and get a new ProgramState with
seaneveson created this revision.
seaneveson added a subscriber: cfe-commits.
Dear All,
I would like to propose a small patch to add an option (-analyzer-config
min-blocks-for-inline-large=14) to control the function size the inliner
considers as large, in relation to max-times-inline-large.
seaneveson added a comment.
In http://reviews.llvm.org/D12358#233983, @zaks.anna wrote:
This will leave us in a state that is wrong and will likely lead to false
positives and inconsistencies, avoiding which is extremely important.
I accept that my current patch is not a comprehensive
51 matches
Mail list logo
