rsmith added inline comments.
Comment at: lib/CodeGen/CGCXXABI.h:221
@@ -220,4 +220,3 @@
- virtual bool canEmitAvailableExternallyVTable(
- const CXXRecordDecl *RD) const = 0;
+ virtual bool canEmitUnusedVTable(const CXXRecordDecl *RD) const = 0;
This w
Author: xazax
Date: Wed Aug 26 18:17:43 2015
New Revision: 246105
URL: http://llvm.org/viewvc/llvm-project?rev=246105&view=rev
Log:
[Static Analyzer] Checks to catch nullability related issues.
Differential Revision: http://reviews.llvm.org/D11468
Added:
cfe/trunk/docs/analyzer/nullability.r
This revision was automatically updated to reflect the committed changes.
Closed by commit rL246105: [Static Analyzer] Checks to catch nullability
related issues. (authored by xazax).
Changed prior to commit:
http://reviews.llvm.org/D11468?vs=33239&id=33267#toc
Repository:
rL LLVM
http://re
Prazek marked 3 inline comments as done.
Prazek added a comment.
http://reviews.llvm.org/D12385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Prazek updated this revision to Diff 33269.
http://reviews.llvm.org/D12385
Files:
lib/CodeGen/CGCXXABI.h
lib/CodeGen/CGClass.cpp
lib/CodeGen/CGVTables.cpp
lib/CodeGen/ItaniumCXXABI.cpp
lib/CodeGen/MicrosoftCXXABI.cpp
test/CodeGenCXX/template-instantiation.cpp
test/CodeGenCXX/thunks.
rsmith accepted this revision.
rsmith added a comment.
This revision is now accepted and ready to land.
LGTM with some comment tweaks.
Comment at: lib/CodeGen/CGClass.cpp:1861
@@ +1860,3 @@
+ // We also have to make sure if we can refer to vtable:
+ // - If vtable is external
On Wed, Aug 26, 2015 at 3:38 PM, Eric Fiselier wrote:
> EricWF added a comment.
>
> In http://reviews.llvm.org/D12247#233717, @yiranwang wrote:
>
>> Hi Eric,
>>
>> Could you please explain a bit more what is broken specifically? As we can
>> see, sizeof(), _Len, and _Align, and alignof() of "alig
Prazek added a comment.
I will wait with pushing for tomorrow noon, in case someone want's to check the
code.
http://reviews.llvm.org/D12385
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-
Prazek marked 2 inline comments as done.
Comment at: lib/CodeGen/CGClass.cpp:1861
@@ +1860,3 @@
+ // We also have to make sure if we can refer to vtable:
+ // - If vtable is external then it's safe to use it (for availabe_externally
+ // CGVTables will make sure if it can emi
Author: hans
Date: Wed Aug 26 18:34:53 2015
New Revision: 246113
URL: http://llvm.org/viewvc/llvm-project?rev=246113&view=rev
Log:
Creating release candidate rc4 from release_370 branch
Added:
libcxx/tags/RELEASE_370/rc4/ (props changed)
- copied from r246112, libcxx/branches/release_
Author: hans
Date: Wed Aug 26 18:34:56 2015
New Revision: 246114
URL: http://llvm.org/viewvc/llvm-project?rev=246114&view=rev
Log:
Creating release candidate rc4 from release_370 branch
Added:
libcxxabi/tags/RELEASE_370/rc4/ (props changed)
- copied from r246113, libcxxabi/branches/re
Author: hans
Date: Wed Aug 26 18:35:14 2015
New Revision: 246120
URL: http://llvm.org/viewvc/llvm-project?rev=246120&view=rev
Log:
Creating release candidate rc4 from release_370 branch
Added:
libunwind/tags/RELEASE_370/rc4/ (props changed)
- copied from r246119, libunwind/branches/re
Prazek updated this revision to Diff 33273.
Prazek marked an inline comment as done.
http://reviews.llvm.org/D12385
Files:
lib/CodeGen/CGCXXABI.h
lib/CodeGen/CGClass.cpp
lib/CodeGen/CGVTables.cpp
lib/CodeGen/ItaniumCXXABI.cpp
lib/CodeGen/MicrosoftCXXABI.cpp
test/CodeGenCXX/template-in
Author: echristo
Date: Wed Aug 26 18:42:18 2015
New Revision: 246122
URL: http://llvm.org/viewvc/llvm-project?rev=246122&view=rev
Log:
Pull out cpu string -> enum parsing for x86 as a separate function,
this is going to see use shortly in unifying feature set construction.
Modified:
cfe/trunk
Author: rsmith
Date: Wed Aug 26 18:55:49 2015
New Revision: 246124
URL: http://llvm.org/viewvc/llvm-project?rev=246124&view=rev
Log:
[modules] The key to a DeclContext name lookup table is not actually a
DeclarationName (because all ctor names are considered the same, and so on).
Reflect this in t
ab created this revision.
ab added a reviewer: rjmccall.
ab added a subscriber: cfe-commits.
The long-overdue (sorry!) prequel to D10724.
http://reviews.llvm.org/D12389
Files:
lib/Basic/Targets.cpp
test/CodeGen/vector-alignment.c
Index: test/CodeGen/vector-alignment.c
==
ab created this revision.
ab added a reviewer: rjmccall.
ab added a subscriber: cfe-commits.
One problem that came up in D12389 is that i386 doesn't know about the "avx"
ABIs. Judging by the commit that originally introduced the X86_64 check and
the "avx" ABI (r145652), it was just unnecessary.
Author: echristo
Date: Wed Aug 26 19:05:50 2015
New Revision: 246127
URL: http://llvm.org/viewvc/llvm-project?rev=246127&view=rev
Log:
const-ify X86TargetInfo::getCPUKind.
Modified:
cfe/trunk/lib/Basic/Targets.cpp
Modified: cfe/trunk/lib/Basic/Targets.cpp
URL:
http://llvm.org/viewvc/llvm-pr
Author: echristo
Date: Wed Aug 26 19:05:52 2015
New Revision: 246128
URL: http://llvm.org/viewvc/llvm-project?rev=246128&view=rev
Log:
Pass in a cpu to initDefaultFeatures so that we can share this code
with multiple uses of feature map construction.
Note: We could make this a static function on
rsmith added a subscriber: rsmith.
Comment at: lib/CodeGen/CGClass.cpp:1369-1382
@@ +1368,16 @@
+
+void VisitCallExpr(const Expr *E) {
+ Sensitive = true;
+}
+void VisitCXXTypeidExpr(const Expr *E) {
+ Sensitive = true;
+}
+void VisitExpr(const Expr *
eugenis added a comment.
Richard, would you mind taking a look a this change?
http://reviews.llvm.org/D12022
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
EricWF added a comment.
In http://reviews.llvm.org/D12247#231444, @yiranwang wrote:
> A test case is as following. It has to be build by GCC 4.9 -O3 (maybe or
> later), with latest libc++, and for AARCH64+ANDROID target.
> AARCH64 requires 128 bit alignment for aligned_storage and 64 bit point
zaks.anna requested changes to this revision.
zaks.anna added a comment.
This revision now requires changes to proceed.
I agree that the way the static analyzer handles loops with known bounds is
quite bad and we loose coverage because of it, so this is definitely an
important problem to solve!
xazax.hun added a comment.
A conservative solution should work.
But if we want to preserve some precision I think it should be possible to not
to invalidate those values on the stack that are not effected by the loop. The
hard problem here is that, it is impossible to reason about the heap with
compnerd added inline comments.
Comment at: lib/Headers/Intrin.h:961
@@ +960,3 @@
+static __inline__ void __DEFAULT_FN_ATTRS _lgdt(void *__ptr) {
+ __builtin_ia32_lgdt(__ptr);
+}
mkuper wrote:
> compnerd wrote:
> > Why does this need a builtin? Is an inline asse
krememek added a comment.
In http://reviews.llvm.org/D12358#233983, @zaks.anna wrote:
> A way this could be improved is by invalidating all the values that the loops
> effects, both the values on the stack and on the heap. (We could even start
> overly conservative and invalidate all the values
> On Aug 26, 2015, at 3:59 AM, Sean Eveson via cfe-commits
> wrote:
>
> 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.
krememek added a comment.
FWIW, I do think this is a great problem to work on. It is easy to come up
with solutions that work for specific examples but fall over on general code.
I completely agree that failing to analyzing code after the loop is a major
hole and lost opportunity to find bugs
krememek added a comment.
One thing about the tests passing: that's great, but that's obviously
insufficient. We probably have fewer tests showing that the analyzer can't
handle something than tests that show it does handle something.
When a patch like this lands, which expands the analysis sc
EricWF added a comment.
I think I've misunderstood this patch the whole time. I didn't understand that
it was undefined to access the trailing padding of the storage type. Am I
correct in saying that this patch won't change the actual values of
`sizeof(aligned_storage::type)` and `sizeof(aligne
davidxl added a comment.
yes -- the intention of Yiran's patch is not to change the size/alignment of
the underlying storage, but to make the original padding space part of the type.
http://reviews.llvm.org/D12247
___
cfe-commits mailing list
cfe-c
101 - 131 of 131 matches
Mail list logo
