Added more cases to deal with new default compiler driver flags that were making builds fail.

llvm-svn: 151954

(from the mnemonic) whether an instruction is a
branch.  This function's result is exposed through
DoesBranch().

llvm-svn: 151953

llvm-svn: 151952

llvm-svn: 151951

the corresponding files to avoid confusion.

This is a preparation to adding an AST-based call graph to Analysis. The
existing call graph works with indexer entries. We might be able to
refactor it to use the AST based graph in the future.

(Minimal testing here as the only example that uses the API has been
completely broken, does not compile.)

llvm-svn: 151950

llvm-svn: 151949

llvm-svn: 151948

llvm-svn: 151947

Hack our project file to deal with new default compiler driver flags that were making builds fail.

llvm-svn: 151946

GNU attributes to a better extent, by allowing them in more
places on a declator.

llvm-svn: 151945

llvm-svn: 151944

It doesn't warn if the integer is known at compile time and within
the bounds of the string.

Discussion: http://comments.gmane.org/gmane.comp.compilers.clang.scm/47203
llvm-svn: 151943

issue the note if it is because message is sent to a forward class
declaration in delayed diagnostic. // rdar://10290322

llvm-svn: 151942

llvm-svn: 151941

llvm-svn: 151940

Add logic to GDBRemoteRegisterContext class to be able to read/write a "composite" register
which has "primordial" registers as its constituents.  In particular, Read/WriteRegisterBytes()
now delegate to Get/SetPrimordialRegister() helper methods to read/write register contents.

Also modify RegisterValue class to be able to parse "register write" string value for the
NEON quadword registers which is displayed as a vector of uint8's.

Example:

(lldb) register write q0 "{0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10}"
(lldb) register read q0
q0 = {0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10}
(lldb) register read --format uint8_t[] s0
s0 = {0x01 0x02 0x03 0x04}
(lldb) register read --format uint8_t[] d0
d0 = {0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08}
(lldb) register read --format uint8_t[] d1
d1 = {0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10}

llvm-svn: 151939

Fixes <rdar://problem/10967815>

llvm-svn: 151938

while still ensuring that the sections get remote
allocations.

llvm-svn: 151936

ptrdiff_t on PPC32 on Linux, etc. should be int not long.
This does not matter for C, but it does matter for C++ because of
name mangling.

The preprocessor test has been changed accordingly.

llvm-svn: 151935

This is consistent with -Wbool-conversion. Let me know if you prefer
a different flag name.

llvm-svn: 151934

llvm-svn: 151932

@class I;
@implementation I(cat) // crashes here
@end

rdar://10968158

llvm-svn: 151931

command line options for inlining tuning.

This adds the option for stack depth bound as well as function size
bound. 

+ minor doxygenification

llvm-svn: 151930

Adding a test case for a bug where types CFGregorianDate and CFRange were improperly uniqued by LLDB such that both where shown as having the same structure contents - The bug itself is fixed in TOT but we want to catch regressions ASAP

llvm-svn: 151929

llvm-svn: 151928

types of the pointer arguments.

llvm-svn: 151927

llvm-svn: 151926

llvm-svn: 151924

// rdar://10961370

llvm-svn: 151923

Revert r151879, r151880, "PR12145: Avoid emitting loads of constexpr variables in contexts where there" and "Fix buildbot: make this test less dependent on the value names in the produced IR."

They broke bootstrap.

llvm-svn: 151922

llvm-svn: 151921

No, really, make doesn't work with spaces.

llvm-svn: 151920

This could probably be made a lot smarter, but this is a common case and doesn't require LVI to scan a lot
of code. With this change CVP can optimize away the "shift == 0" case in Hashing.h that only gets hit when
"shift" is in a range not containing 0.

llvm-svn: 151919

Hashing: microoptimize a truncate on 64 bit away. This currently blocks dead code eliminating the conditional.

The optimizer should handle this eventually, but currently LVI isn't really designed for this kind of stuff.

llvm-svn: 151918

llvm-svn: 151917

llvm-svn: 151916

llvm-svn: 151915

llvm-svn: 151914

llvm-svn: 151913

llvm-svn: 151912