compile commands of the database and expose it via the libclang API.

llvm-svn: 169226

FIXME: I have not checked whether to be compiled on msvc11.
llvm-svn: 169225

missed in the first pass because the script didn't yet handle include
guards.

Note that the script is now able to handle all of these headers without
manual edits. =]

llvm-svn: 169224

llvm-svn: 169223

1) Teach it to handle files with #include on the first line -- these do
   actually exist in LLVM.
2) Support llvm-c and clang-c include projects.
3) Nuke some stail imports.
4) Switch to using os.path to split the file extension off.
5) Remove debugging leftovers.
6) Add docstring (a really puny one) for the sort function.

I'm continuing te avoid stripping the whitespace on the RHS to preserve
whatever newline characters happen to be in the original file.

llvm-svn: 169222

This comment has the dual effect of blocking reorderings with the
sort_include script.

llvm-svn: 169221

clang/test/CodeGenCXX/debug-info-zero-length-arrays.cpp: Add explicit triple, x86_64-unknown-unknown. It was incompatible to i686.

llvm-svn: 169220

The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.

llvm-svn: 169219

The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.

llvm-svn: 169218

Add the last part that is needed for vectorization of if-converted code.
Added the code that actually performs the if-conversion during vectorization.

We can now vectorize this code:

for (int i=0; i<n; ++i) {
  unsigned k = 0;

  if (a[i] > b[i])   <------ IF inside the loop.
    k = k * 5 + 3;

  a[i] = k;          <---- K is a phi node that becomes vector-select.
}

llvm-svn: 169217

[asan] add experimental -asan-realign-stack option (true by default, which does not change the current behavior) 

llvm-svn: 169216

llvm-svn: 169215

llvm-svn: 169214

llvm-svn: 169213

llvm-svn: 169212

llvm-svn: 169211

Apparently Dinkumware are no longer hosting their nice reference
manuals. Thankfully, `cppreference.com` can fill that role well.

llvm-svn: 169210

The type of shirt-right (logical or arithemetic) should remain unchanged 
when transforming  "X << C1 >> C2" into "X << (C1-C2)"

llvm-svn: 169209

Patch by Alexander Zinenko!

llvm-svn: 169208

llvm-svn: 169207

Need to define MISSING_BLOCKS_SUPPORT in this case at buildtime.

Patch by Jack Howarth <howarth@bromo.med.uc.edu>
 

llvm-svn: 169206

Add the ability to get a symbol or symbols by name and type from a SBModule, and also the ability to get all symbols by name and type from SBTarget objects.

llvm-svn: 169205

llvm-svn: 169203

llvm-svn: 169202

ASan: add new interface functions - __asan_(un)poison_stack_memory. Calls to these functions are inserted by the instrumentation pass in use-after-scope mode

llvm-svn: 169201

ASan: add initial support for handling llvm.lifetime intrinsics in ASan - emit calls into runtime library that poison memory for local variables when their lifetime is over and unpoison memory when their lifetime begins.

llvm-svn: 169200

llvm-svn: 169199

llvm-svn: 169198

the alignment is clamped to TargetFrameLowering.getStackAlignment if the target
does not support stack realignment or the option "realign-stack" is off.

This will cause miscompile if the address is treated as aligned and add is
replaced with or in DAGCombine.

Added a bool StackRealignable to TargetFrameLowering to check whether stack
realignment is implemented for the target. Also added a bool RealignOption
to MachineFrameInfo to check whether the option "realign-stack" is on.

rdar://12713765

llvm-svn: 169197

llvm-svn: 169196

llvm-svn: 169195

llvm-svn: 169194

<declaration> tag of Comment XML and fixed a
missing declaration of ivars private to @implementation
as result of the testing. // rdar://12378714

llvm-svn: 169193

These functions have been replaced by TRI::getRegAllocationHints() which
provides the same capabilities.

llvm-svn: 169192

Have clang use LLVM IR's fast-math flags when in FastMath or FiniteMathOnly modes. Test cases included.

llvm-svn: 169191

Now that there can be multiple hint registers from targets, it doesn't
make sense to have a function that returns 'the' preferred register.

llvm-svn: 169190

Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite.

This fix does the following:
- make sure all short options are treated as "int"
- make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired
- fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates
- fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value

llvm-svn: 169189

Targets can provide multiple hints now, so getRegAllocPref() doesn't
make sense any longer because it only returns one preferred register.
Replace it with getSimpleHint() in the remaining heuristics. This
function only

llvm-svn: 169188

llvm-svn: 169187

No functional change for this commit. The follow-up patch will add more stuff to
these functions.

rdar://12713765

llvm-svn: 169186