is not a directory, Driver::GetProgramPath() routine does not try to append
the program name as a "path component" to it. It just joins the "prefix" with
the program name and checks the resulting path existence.
The patch reviewed by Rafael Espindola.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167114 91177308-0d34-0410-b5e6-96231b3b80d8
If HA can only partially fit into VFP registers, we add padding to make sure
HA will be on stack and later VFP CPRCs will be on stack as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167058 91177308-0d34-0410-b5e6-96231b3b80d8
later, '-L <dir>' is allowed, but rewrite these in the driver as '-L<dir>' to
maintain backward compatibility. The same is true for the -I option.
rdar://12366753
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167054 91177308-0d34-0410-b5e6-96231b3b80d8
The ImmutableMap should not be the key into the GDM map as there could
be several entries with the same map type. Thanks, Jordan.
This complicates the usage of the macro a bit. When we want to retrieve
the whole map, we need to use another name. Currently, I set it to be
Name ## Ty as in "type of the map we are storing in the ProgramState".
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167000 91177308-0d34-0410-b5e6-96231b3b80d8
This is a syntactic checker aimed at helping iOS programmers correctly
subclass and override the methods of UIViewController. While this should
eventually be covered by the 'objc_requires_super' attribute, this
checker can be used with the existing iOS SDKs without any header changes.
This new checker is currently named 'alpha.osx.cocoa.MissingSuperCall'.
Patch by Julian Mayer!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166993 91177308-0d34-0410-b5e6-96231b3b80d8
we had the -ccc-clang-cxx and -ccc-no-clang-cxx options to force them
on or off for testing.
Clang c++ support is now production quality and these options are dead.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166986 91177308-0d34-0410-b5e6-96231b3b80d8
The problem is as follows: C++11 has contexts which are not
potentially-evaluated, and yet in which we are required or encouraged to
perform constant evaluation. In such contexts, we are not permitted to
implicitly define special member functions for literal types, therefore
we cannot evalaute those constant expressions.
Punt on this in one more context for now by skipping checking constexpr
variable initializers if they occur in dependent contexts.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166956 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the warning would erroneously fire on this:
for (Test *a in someArray)
use(a.weakProp);
...because it looks like the same property is being accessed over and over.
However, clearly this is not the case. We now ignore loops like this for
local variables, but continue to warn if the base object is a parameter,
global variable, or instance variable, on the assumption that these are
not repeatedly usually assigned to within loops.
Additionally, do-while loops where the condition is 'false' are not really
loops at all; usually they're just used for semicolon-swallowing macros or
using "break" like "goto".
<rdar://problem/12578785&12578849>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166942 91177308-0d34-0410-b5e6-96231b3b80d8
Our one basic suppression heuristic is to assume that functions do not
usually return NULL. However, when one of the arguments is NULL it is
suddenly much more likely that NULL is a valid return value. In this case,
we don't suppress the report here, but we do attach /another/ visitor to
go find out if this NULL argument also comes from an inlined function's
error path.
This new behavior, controlled by the 'avoid-suppressing-null-argument-paths'
analyzer-config option, is turned off by default. Turning it on produced
two false positives and no new true positives when running over LLVM/Clang.
This is one of the possible refinements to our suppression heuristics.
<rdar://problem/12350829>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166941 91177308-0d34-0410-b5e6-96231b3b80d8
Additionally, don't collect PostStore nodes -- they are often used in
path diagnostics.
Previously, we tried to track null arguments in the same way as any other
null values, but in many cases the necessary nodes had already been
collected (a memory optimization in ExplodedGraph). Now, we fall back to
using the value of the argument at the time of the call, which may not
always match the actual contents of the region, but often will.
This is a precursor to improving our suppression heuristic.
<rdar://problem/12350829>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166940 91177308-0d34-0410-b5e6-96231b3b80d8
ELF subtarget.
The existing description string is moved from PPC64TargetInfo to its
DarwinTargetInfo subclass, to avoid any changes to the Darwin ABI.
PPC64TargetInfo now has two possible description strings: one for FreeBSD,
which requires 8-byte alignment, and a default string that requires
16-byte alignment.
I've added a test for PPC64 Linux to verify the 16-byte alignment. If
somebody wants to add a separate test for FreeBSD, that would be great.
Note that there is a companion patch to update the alignment information
in LLVM, which I am committing now as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166927 91177308-0d34-0410-b5e6-96231b3b80d8