| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 168265
|
|
|
|
|
|
| |
Also fixes a bit/byte mismatch when checking if a target supports atomic ops of a certain size.
llvm-svn: 168260
|
|
|
|
|
|
| |
It's also simpler to just copy the words than mangling bits like this ctor did.
llvm-svn: 168258
|
|
|
|
|
|
| |
2.5% using intelligent pruning of blocks during the final reporting pass.
llvm-svn: 168257
|
|
|
|
|
|
|
|
|
| |
an initial baseline for enqueued blocks, but use a simple DFS stack
for propagating changes quickly up back edges.
This provides a 3.5% reduction in -fsyntax-only time on sqlite3.c.
llvm-svn: 168241
|
|
|
|
|
|
| |
Jung-uk Kim.
llvm-svn: 168239
|
|
|
|
|
|
| |
functional change. Patch by Jung-uk Kim.
llvm-svn: 168237
|
|
|
|
| |
llvm-svn: 168222
|
|
|
|
|
|
| |
it was intended to fix.
llvm-svn: 168217
|
|
|
|
|
|
| |
fragile.
llvm-svn: 168213
|
|
|
|
|
|
|
|
|
| |
This was causing different behavior when using -x objective-c++-cpp-output as
compared to -x objc++-cpp-output. Specifically, the driver was not adding the
-fcxx-exceptions flag in the latter case.
rdar://12680312
llvm-svn: 168212
|
|
|
|
|
|
|
|
|
| |
There are better ways of limiting the amount of information if there is a need
for that.
Patch by Philip Craig.
llvm-svn: 168206
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that a partial match of an (explicit or implicit) allOf matcher
binds results, i.e.
recordDecl(decl().bind("x"), hasName("A"))
can very well bind a record that is not named "A". With this fix, the common
cases of stumbling over this bug are fixed by the BoundNodesMap overwriting the
results of a partial match. An error can still be created with a weird
combination of anyOf and allOf (see inactive test). We need to decide whether
this is worth fixing, as the fix will have performance impact.
Review: http://llvm-reviews.chandlerc.com/D124
llvm-svn: 168177
|
|
|
|
|
|
|
|
| |
This has been broken for a while, but the branch was never being taken.
(We were trying to do 'str + floatVal'; now we do 'str % intVal' and use
the '%d' format.)
llvm-svn: 168174
|
|
|
|
|
|
|
|
| |
libRewriteCore.
LLVM_USED_LIBS does nothing here.
llvm-svn: 168172
|
|
|
|
|
|
| |
ubsan on OS X in 'make' build system. Patch by Jean-Daniel Dupas.
llvm-svn: 168168
|
|
|
|
| |
llvm-svn: 168145
|
|
|
|
| |
llvm-svn: 168137
|
|
|
|
|
|
| |
it as a pointer.
llvm-svn: 168136
|
|
|
|
| |
llvm-svn: 168135
|
|
|
|
|
|
| |
now." I missed Daniel's r168095 by my accident.
llvm-svn: 168134
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
CachedCompletionAllocator
to the CodeCompletionTUInfo that is going to be used to get the results.
Previously we would use ASTUnit's CodeCompletionTUInfo which has its own allocator
that will go away when we reparse. That could result in a use-after-free bug when
getting the parent context name from a CodeCompletionString.
Addresses rdar://12568377.
llvm-svn: 168133
|
|
|
|
|
|
| |
None of my buildhost (centos6 x86-64 and cygwin) is passing. Investigating.
llvm-svn: 168132
|
|
|
|
|
|
|
|
| |
- This diverges from gcc, and confuses tools (like dtrace) which track # line
markers as a way to determine which content is in the context of the main
file.
llvm-svn: 168128
|
|
|
|
|
|
|
| |
width of an enum with negative values in IntRange. Include a test for
-Wtautological-constant-out-of-range-compare where this had manifested.
llvm-svn: 168126
|
|
|
|
|
|
|
|
|
| |
GCC 4.7 reuses stack slots fairly aggressively, which exposes more temporary
lifetime bugs.
No new test, this was caught by the existing CodeGenCXX/mangle-ms-templates.cpp.
llvm-svn: 168124
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
|
|
|
|
| |
llvm-svn: 168118
|
|
|
|
| |
llvm-svn: 168117
|
|
|
|
|
|
| |
a crash in IR generation.
llvm-svn: 168112
|
|
|
|
|
|
|
| |
dropping the specifier, just like we do for non-member functions and function
templates declared 'typedef'. Patch by Brian Brooks!
llvm-svn: 168108
|
|
|
|
|
|
| |
report)
llvm-svn: 168105
|
|
|
|
| |
llvm-svn: 168101
|
|
|
|
| |
llvm-svn: 168099
|
|
|
|
|
|
| |
and a non-fragile (that uses [[@LINE]]) parts.
llvm-svn: 168098
|
|
|
|
| |
llvm-svn: 168095
|
|
|
|
|
|
| |
"<invalid loc>" for summary.
llvm-svn: 168087
|
|
|
|
|
|
|
| |
- An LLVM unique_file() bug could cause us to infinite loop on the later test
case.
llvm-svn: 168082
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In code like this:
void foo() {
bar();
baz();
}
...the location for the call to 'bar()' was being used as a backup location
for the call to 'baz()'. This is fine unless the call to 'bar()' is deemed
uninteresting and that part of the path deleted.
(This looks like a logic error as well, but in practice the only way 'baz()'
could have an invalid location is if the entire body of 'foo()' is
synthesized, meaning the call to 'bar()' will be using the location of the
call to 'foo()' anyway. Nevertheless, the new version better matches the
intent of the code.)
Found by Matt Beaumont-Gay using ASan. Thanks, Matt!
llvm-svn: 168080
|
|
|
|
|
|
| |
- Realized I could use the /dev/fd filesystem to make a simple portable test.
llvm-svn: 168079
|
|
|
|
| |
llvm-svn: 168077
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a few cases where we'd emit path notes like this:
+---+
1| v
p = malloc(len);
^ |2
+---+
In general this should make path notes more consistent and more correct,
especially in cases where the leak happens on the false branch of an if
that jumps directly to the end of the function. There are a couple places
where the leak is reported farther away from the cause; these are usually
cases where there are several levels of nested braces before the end of
the function. This still matches our current behavior for when there /is/
a statement after all the braces, though.
llvm-svn: 168070
|
|
|
|
|
|
|
| |
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
llvm-svn: 168069
|
|
|
|
|
|
|
| |
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
llvm-svn: 168068
|
|
|
|
|
|
|
| |
Also, don't bother to stop tracking symbols in the return value, either.
They are now properly considered live during checkDeadSymbols.
llvm-svn: 168067
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows us to properly remove dead bindings at the end of the top-level
stack frame, using the ReturnStmt, if there is one, to keep the return value
live. This in turn removes the need for a check::EndPath callback in leak
checkers.
This does cause some changes in the path notes for leak checkers. Previously,
a leak would be reported at the location of the closing brace in a function.
Now, it gets reported at the last statement. This matches the way leaks are
currently reported for inlined functions, but is less than ideal for both.
llvm-svn: 168066
|
|
|
|
|
|
|
|
| |
to a cc1 -fencode-extended-block-signature and pass it
to cc1 and recognize this option to produce extended block
type signature. // rdar://12109031
llvm-svn: 168063
|
|
|
|
|
|
| |
instead of messing with virtual files.
llvm-svn: 168062
|
|
|
|
|
|
| |
as the include location of the main file of an imported module.
llvm-svn: 168061
|
|
|
|
|
|
| |
FileCheck feature. This will hopefully make tests less fragile.
llvm-svn: 168056
|