integer promotion analogous to vector promotion. When there is an
integer alloca being accessed both as its integer type and as a narrower
integer type, promote the narrower access to "insert" and "extract" the
smaller integer from the larger one, and make the integer alloca
a candidate for promotion.

In the new formulation, we don't care about target legal integer or use
thresholds to control things. Instead, we only perform this promotion to
an integer type which the frontend has already emitted a load or store
for. This bounds the scope and prevents optimization passes from
coalescing larger and larger entities into a single integer.

llvm-svn: 164479

unittests/AST/StmtPrinterTest.cpp: Suppress a LP64-assumed test, "0x100000000i128 => 4294967296L", for now.

LONG_MAX is 2147483647L on common 32 bit and LLP64 (Windows x64).

llvm-svn: 164478

printing directly rather than through a complicated machinery of ObjC rewriter.

llvm-svn: 164477

Patch by Kai!

llvm-svn: 164476

across the uses of the alloca. It's entirely possible for negative
numbers to come up here, and in some rare cases simply doing the 2's
complement arithmetic isn't the correct decision. Notably, we can't zext
the index of the GEP. The definition of GEP is that these offsets are
sign extended or truncated to the size of the pointer, and then wrapping
2's complement arithmetic used.

This patch fixes an issue that comes up with *no* input from the
buildbots or bootstrap afaict. The only place where it manifested,
disturbingly, is Clang's own regression test suite. A reduced and
targeted collection of tests are added to cope with this. Note that I've
tried to pin down the potential cases of overflow, but may have missed
some cases. I've tried to add a few cases to test this, but its hard
because LLVM has quite limited support for >64bit constructs.

llvm-svn: 164475

llvm-svn: 164474

llvm-svn: 164473

llvm-svn: 164472

llvm-svn: 164471

llvm-svn: 164470

llvm-svn: 164469

llvm-svn: 164468

deprecation attribute ('deprecated', 'availability' or 'unavailable').

This warning is under a separate flag, -Wdocumentation-deprecated-sync, so it
can be turned off easily while leaving other -Wdocumentation warnings on.

llvm-svn: 164467

llvm-svn: 164466

llvm-svn: 164465

The issue is that we were calling clang_getCompletionBriefComment
unconditionally.  New we check if this function is available before calling it.

llvm-svn: 164464

llvm-svn: 164462

using getArch, but I will try to fix them one at time to add tests.

llvm-svn: 164460

llvm-svn: 164459

llvm-svn: 164458

As before with load instructions, oddities like "asr #32", "rrx" could
be printed incorrectly.

Patch by Chris Lidbury.

llvm-svn: 164456

This patch fixes load/store instructions to handle less common cases
like "asr #32", "rrx" properly throughout the MC layer.

Patch by Chris Lidbury.

llvm-svn: 164455

llvm-svn: 164454

llvm-svn: 164453

llvm-svn: 164452

Allow subtargets to tie SchedReadWrite types to processor specific
sequences or variants.

llvm-svn: 164451

FunctionDecl that we are importing the FunctionProtoType for, in which case we'll have
infinite recursion when importing.

Initially create a FunctionProtoType with null ExceptionSpecDecl/ExceptionSpecTemplate and
update the type in ASTNodeImporter::VisitFunctionDecl after the FunctionDecl has been created.

llvm-svn: 164450

This is a heuristic intended to greatly reduce the number of false
positives resulting from inlining, particularly inlining of generic,
defensive C++ methods that live in header files. The suppression is
triggered in the cases where we ask to track where a null pointer came
from, and it turns out that the source of the null pointer was an inlined
function call.

This change brings the number of bug reports in LLVM from ~1500 down to
around ~300, a much more manageable number. Yes, some true positives may
be hidden as well, but from what I looked at the vast majority of silenced
reports are false positives, and many of the true issues found by the
analyzer are still reported.

I'm hoping to improve this heuristic further by adding some exceptions
next week (cases in which a bug should still be reported).

llvm-svn: 164449

Also, tidy up the other tracking visitors so that they mark the right
things as interesting and don't do extra work.

llvm-svn: 164448

Before, PathDiagnosticConsumers that did not support actual path output
would (sensibly) cause the generation of the full path to be skipped.
However, BugReporterVisitors may want to see the path in order to mark a
BugReport as invalid.

Now, even for a path generation scheme of 'None' we will still create a
trimmed graph and walk backwards through the bug path, doing no work other
than passing the nodes to the BugReporterVisitors. This isn't cheap, but
it's necessary to properly do suppression when the first path consumer does
not support path notes.

In the future, we should try only generating the path and visitor-provided
path notes once, or at least only creating the trimmed graph once.

llvm-svn: 164447

This is intended to allow visitors to make decisions about whether a
BugReport is likely a false positive. Currently there are no visitors
making use of this feature, so there are no tests.

When a BugReport is marked invalid, the invalidator must provide a key
that identifies the invaliation (intended to be the visitor type and a
context pointer of some kind). This allows us to reverse the decision
later on. Being able to reverse a decision about invalidation gives us more
flexibility, and allows us to formulate conditions like "this report is
invalid UNLESS the original argument is 'foo'". We can use this to
fine-tune our false-positive suppression (coming soon).

llvm-svn: 164446

This allows us to show /why/ a particular object is nil, even when it is
wrapped in an OpaqueValueExpr.

llvm-svn: 164445

Rather than saying "Null pointer value stored to 'foo'", we now say
"Passing null pointer value via Nth parameter 'foo'", which is much better.
The note is also now on the argument expression as well, rather than the
entire call.

This paves the way for continuing to track arguments back to their sources.

<rdar://problem/12211490>

llvm-svn: 164444

Just a refactoring of common infrastructure. No intended functionality change.

llvm-svn: 164443

Like with struct fields, we want to catch cases like this early,
so that we can produce better diagnostics and path notes:

  PointObj *p = nil;
  int *px = &p->_x; // should warn here
  *px = 1;

llvm-svn: 164442

We want to catch cases like this early, so that we can produce better
diagnostics and path notes:

  Point *p = 0;
  int *px = &p->x; // should warn here
  *px = 1;

llvm-svn: 164441

Used by clang to print parameter indexes.

llvm-svn: 164440

This silences several analyzer warnings within LLVM, and provides a slightly
nicer crash experience when someone calls isa<>, cast<>, or dyn_cast<> with
a null pointer.

llvm-svn: 164439

This silences literally dozens of analyzer warnings on LLVM (since DenseMap
is such a commonly-used class).

llvm-svn: 164438

fatal error. Previously, if a fatal error was followed by a diagnostic which
was suppressed due to a SFINAETrap, we'd forget that we'd seen a fatal error.

llvm-svn: 164437