conditions.  Add a fixit to insert the parentheses.  Also fix a very minor
possible memory leak in 'for' conditions.

Fixes PR 4876 and rdar://problem/7289172

llvm-svn: 83907

llvm-svn: 83905

llvm-svn: 83904

MultiSource/Benchmarks/MiBench/automotive-susan test.  The failure has
since been masked by an unrelated change (just randomly), so I don't have
a testcase for this now.  Radar 7291928.

The situation where this happened is that a constant pool entry (CPE) was
placed at a lower address than the load that referenced it.  There were in
fact 2 CPEs placed at adjacent addresses and referenced by 2 loads that were
close together in the code.  The distance from the loads to the CPEs was
right at the limit of what they could handle, so that only one of the CPEs
could be placed within range.  On every iteration, the first CPE was found
to be out of range, causing a new CPE to be inserted.  The second CPE had
been in range but the newly inserted entry pushed it too far away.  Thus the
second CPE was also replaced by a new entry, which in turn pushed the first
CPE out of range.  Etc.

Judging from some comments in the code, the initial implementation of this
pass did not support CPEs placed _before_ their references.  In the case
where the CPE is placed at a higher address, the key to making the algorithm
terminate is that new CPEs are only inserted at the end of a group of adjacent
CPEs.  This is implemented by removing a basic block from the "WaterList"
once it has been used, and then adding the newly inserted CPE block to the
list so that the next insertion will come after it.  This avoids the ping-pong
effect where CPEs are repeatedly moved to the beginning of a group of
adjacent CPEs.  This does not work when going backwards, however, because the
entries at the end of an adjacent group of CPEs are closer than the CPEs
earlier in the group.

To make this pass terminate, we need to maintain a property that changes can
only happen in some sort of monotonic fashion.  The fix used here is to require
that the CPE for a particular constant pool load can only move to lower
addresses.  This is a very simple change to the code and should not cause
any significant degradation in the results.

llvm-svn: 83902

llvm-svn: 83901

llvm-svn: 83900

Use a BumpPtrAllocator to allocate all aspects of CFG, including CFGBlocks, successor and predecessor vectors, etc.

Speedup: when doing 'clang-cc -analyze -dump-cfg' (without actual printing, just
CFG building) on the amalgamated SQLite source (all of SQLite in one source
file), runtime reduced by 9%.

This fixes: <rdar://problem/7250745>

llvm-svn: 83899

llvm-svn: 83898

llvm-svn: 83897

llvm-svn: 83896

producing any stores at all for a long time, but ".store." was in some
IR instruction names until recently.  This removal caused the test to
start failing.  Just make it reject any stores.

llvm-svn: 83895

llvm-svn: 83894

llvm-svn: 83893

instantiation has already been required. To do so, keep track of the
point of instantiation for anything that can be instantiated.

llvm-svn: 83890

wip - To prune excessive reporting.

llvm-svn: 83889

llvm-svn: 83888

llvm-svn: 83886

llvm-svn: 83884

llvm-svn: 83883

llvm-svn: 83882

Factor out devirtualization checking into a separate function and make it handle references correctly.

llvm-svn: 83880

llvm-svn: 83874

llvm-svn: 83873

llvm-svn: 83872

bootstrap of FSF-style PPC, so there is some
reason to believe the original bug (which was
never analyzed) has been fixed, probably by
82266.

llvm-svn: 83871

llvm-svn: 83870

canonical conversion types.

llvm-svn: 83869

llvm-svn: 83868

llvm-svn: 83865

user-defined type conversions, issue list of ambiguites in addition 
to the diagnostic. So, clang now issues the following:

b.cpp:19:19: error: left hand operand to ->* must be a pointer to class compatible with the right hand operand, but is 'struct C1'
        int i = c1->*pmf;
                ~~^
b.cpp:19:19: note: because of ambiguity in conversion of 'struct C1' to 'struct E *'
b.cpp:5:5: note: candidate function
    operator E*();
    ^
b.cpp:11:5: note: candidate function
    operator E*();
    ^

llvm-svn: 83862

same Value without breaking things.

llvm-svn: 83861

llvm-svn: 83860

llvm-svn: 83857

llvm-svn: 83856

Fix exclusion of .tmp, which in turn enables installation of $(PROJ_OBJ_ROOT)/tools/clang/include/*.inc.

llvm-svn: 83855

llvm-svn: 83854

it to hold the address of an sret return value, for x86-64 ABI purposes.

Also, fix the test that was originally intended to test this to actually
test it, using FileCheck.

llvm-svn: 83853

llvm-svn: 83852

llvm-svn: 83851

llvm-svn: 83850