didn't delete the original, and now they've diverged. I have no idea what's
going on. Apply my patch in r176173 to this one too, this one looks newer?
llvm-svn: 176236
- made sure we tell Clang not to try to
complete the type since it can't be
completed from its origin any more; and
- fixed a silly bug where we tried to
forget about the original decl's origins
rather than the deported decl's origin.
These produced some crashes in ptr_refs,
especially under libgmalloc.
<rdar://problem/13256150>
llvm-svn: 176233
By returning the (key, value) binding pairs, we save lookups afterwards.
This also enables further work later on.
No functionality change.
llvm-svn: 176230
to create the parent path.
This can happen if the path is a relative filename and the current directory was removed.
Thanks to Daniel D. for the hint in fixing it.
llvm-svn: 176226
This problem is exposed by r171325 which is already reverted. It is rather
hard to fabricate a testing case without it.
r171325 should *NOT* be resurrected as it has a potential problem although
this problem dosen't directly contribute to PR14988.
The bug is tracked by:
- rdar://13063553, and
- http://llvm.org/bugs/show_bug.cgi?id=14988
Thank Arnold for coming up a better solution to this problem. After
comparing this solution and my original proposal, I decided to ditch mine.
llvm-svn: 176225
definition DIE (TAG_variable), and put AT_MIPS_linkage_name to TAG_member when
DarwinGDBCompat is true.
Darwin GDB needs AT_MIPS_linkage_name at both places to work.
Follow-up patch to r176143.
rdar://problem/13291234
llvm-svn: 176220
Test case is missing due to it not being reachable through the current tools
but out of tree code such as the sample at
http://llvm.org/docs/tutorial/LangImpl4.html
Patch by Peng Cheng <gm4cheng@gmail.com>
llvm-svn: 176213
in the Process destructor. Doing it there can be too late depending on what the internal state
and ProcessGDBRemote Async threads are doing.
<rdar://problem/13297536>
llvm-svn: 176203
Consider this case:
int *p = 0;
p = getPointerThatMayBeNull();
*p = 1;
If we inline 'getPointerThatMayBeNull', we might know that the value of 'p'
is NULL, and thus emit a null pointer dereference report. However, we
usually want to suppress such warnings as error paths, and we do so by using
FindLastStoreBRVisitor to see where the NULL came from. In this case, though,
because 'p' was NULL both before and after the assignment, the visitor
would decide that the "last store" was the initialization, not the
re-assignment.
This commit changes FindLastStoreBRVisitor to consider all PostStore nodes
that assign to this region. This still won't catches changes made directly
by checkers if they re-assign the same value, but it does handle the common
case in user-written code and will trigger ReturnVisitor's suppression
machinery as expected.
<rdar://problem/13299738>
llvm-svn: 176201
This enables constructor inlining for types with non-trivial destructors.
The plan is to enable destructor inlining within the next month, but that
needs further verification.
<rdar://problem/12295329>
llvm-svn: 176200
single translation unit should prevent later phases from executing. Otherwise,
this generates lots of noise in build systems. This a fallout from r173825.
Patch by Matthew Curtis <mcurtis@codeaurora.org>.
rdar://13298009
llvm-svn: 176198
This fixes an issue where trying to assemlbe valid ADR instructions would cause
LLVM to hit a failed assertion.
Patch by Keith Walker.
llvm-svn: 176189
This properly asks TargetLibraryInfo if a call is available and if it is, it
can be translated into the corresponding LLVM builtin. We don't vectorize sqrt()
yet because I'm not sure about the semantics for negative numbers. The other
intrinsic should be exact equivalents to the libm functions.
Differential Revision: http://llvm-reviews.chandlerc.com/D465
llvm-svn: 176188
Daniel Jasper