Most map types have an operator[] that inserts a new element if the key
isn't found, then returns a reference to the value slot so that you can
assign into it. However, if the value type is a pointer, it will be
initialized to null. This is usually no problem.

However, if the user /knows/ the map contains a value for a particular key,
they may just use it immediately:

   // From ClangSACheckersEmitter.cpp
   recordGroupMap[group]->Checkers

In this case the analyzer reports a null dereference on the path where the
key is not in the map, even though the user knows that path is impossible
here. They could silence the warning by adding an assertion, but that means
splitting up the expression and introducing a local variable. (Note that
the analyzer has no way of knowing that recordGroupMap[group] will return
the same reference if called twice in a row!)

We already have logic that says a null dereference has a high chance of
being a false positive if the null came from an inlined function. This
patch simply extends that to references whose rvalues are null as well,
silencing several false positives in LLVM.

<rdar://problem/13239854>

llvm-svn: 176371

llvm-svn: 176370

- These tests wont't crash on trunk but would be better to add them so that
  they don't break again in the future.

llvm-svn: 176369

handle indirect register inputs.
rdar://13322011

llvm-svn: 176367

Fixes PR15384.

llvm-svn: 176366

This reduces the time actually spent doing string to ID conversion and shows a 10% improvement in compile time for a particularly bad case that involves ARM Neon intrinsics (these have many overloads).

Patch by Jean-Luc Duprat!

llvm-svn: 176365

- ISD::SHL/SRL/SRA must have either both scalar or both vector operands
  but TLI.getShiftAmountTy() so far only return scalar type. As a
  result, backend logic assuming that breaks.
- Rename the original TLI.getShiftAmountTy() to
  TLI.getScalarShiftAmountTy() and re-define TLI.getShiftAmountTy() to
  return target-specificed scalar type or the same vector type as the
  1st operand.
- Fix most TICG logic assuming TLI.getShiftAmountTy() a simple scalar
  type.

llvm-svn: 176364

dispatch code.  As far as I can tell the thumb2 code is behaving as expected.
I was able to compile and run the associated test case for both arm and thumb1.
rdar://13066352

llvm-svn: 176363

- expected to fail across the board due to llvm.org/pr15401

Patch by Ashok Thirumurthi!

llvm-svn: 176362

This fixes the rest of llvm.org/PR15062.

llvm-svn: 176361

llvm-svn: 176360

Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 176359

llvm-svn: 176358

Update TestCallStdStringFunction to expected fail for gcc and account for multiple breakpoint locations.

Patch from Ashok Thirumurthi.

llvm-svn: 176357

Before:
void f(Type(*parameter)[10]) {}
int(*func)(void *);

After:
void f(Type (*parameter)[10]) {}
int (*func)(void *);

llvm-svn: 176356

llvm-svn: 176354

llvm-svn: 176353

In builder type call, we indent to the laster function calls.
However, for the last element of such a call, we don't need to do
so, as that normally just wastes space and does not increase
readability.

Before:
aaaaaa->aaaaaa->aaaaaa( // break
                  aaaaaa);
aaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaa
    ->aaaaaaaaaaaaaaaaaaaaaaaaaa(
        aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

After:
aaaaaa->aaaaaa->aaaaaa( // break
    aaaaaa);
aaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaa->aaaaaaaaaaaaaaaaaaaaaaaaaa(
    aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa);

llvm-svn: 176352

This fixed llvm.org/PR15378.

llvm-svn: 176351

We now break at a slash if we do not find a space to break on.

Also fixes a bug where we would go over the limit when breaking the
second line.

llvm-svn: 176350

If we don't find a natural split point (currently space) in a string
literal protruding over the line, we just split at the last possible
point.

llvm-svn: 176349

Remove GCInfoDeleter from passes and comments.

llvm-svn: 176347

v2: based on Michels patch, but now allows copying of all registers sizes.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 176346

They won't match anyway.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 176345

It's much easier to specify the encoding with tablegen directly.

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 176344

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 176343

Signed-off-by: Christian König <christian.koenig@amd.com>
llvm-svn: 176342

llvm-svn: 176341

New allocator has 1.5x memory overhead of the old one.

llvm-svn: 176340

whether we already have a method.  Fixes a bug where we were
failing to properly contextually convert a message receiver
during template instantiation.

As a side-effect, we now actually perform correct method lookup
after adjusting a message-send to integral or non-ObjC pointer
types (legal outside of ARC).

rdar://13305374

llvm-svn: 176339

llvm-svn: 176338

llvm-svn: 176337

of block declarators.  Document the rule we use.

Also document the rule that Doug implemented a few weeks ago
which drops ownership qualifiers on function result types.

rdar://10127067

llvm-svn: 176336

Reword the FAQ to stress more that the assert should be used only in case
the developer is sure that the issue is a false positive.

llvm-svn: 176335

llvm-svn: 176334

llvm-svn: 176333

Previously we would return null for an out-of-date file. This inhibited ASTReader::ReadSLocEntry
from creating a FileID to recover gracefully in such a case.

llvm-svn: 176332

In SourceManager::getFileIDLoaded(), add some sanity checks to make sure we don't enter an infinite loop.

rdar://13120919

llvm-svn: 176331

llvm-svn: 176330

successor basic blocks.

Currently this is off by default.

llvm-svn: 176329