and apparently unused (and since they are untested, they're presumably also
broken).

llvm-svn: 167210

llvm-svn: 167209

llvm-svn: 167208

llvm-svn: 167207

launch process (null)" because we changed argv while doing argument
parsing.

llvm-svn: 167202

the receiver of an ObjC message expression.

rdar://12578643

llvm-svn: 167201

llvm-svn: 167200

llvm-svn: 167199

The static compose() function in RegisterCoalescer was doing the exact
same thing.

llvm-svn: 167198

There seems to be some odd corner case where we shut down the ProcessGDBRemote, but we haven't managed to shut down the async thread.  That causes the ProcessGDBRemote::AsyncThread to crash when it wakes up.  So I changed StartAsyncThread and StopAsyncThread to be callable multiple times (only the first one does anything) so that we can just shut it down unequivocally in the ProcessGDBRemote destructor.

<rdar://problem/12602981>

llvm-svn: 167197

llvm-svn: 167196

Specifically, if adding a constraint makes the current system infeasible,
assume the constraint is false, instead of attempting to add its negation.

In +Asserts builds we will still assert that at least one state is feasible.

Patch by Ryan Govostes!

llvm-svn: 167195

Switch from using KERN_PROCARGS2 to get the path to the executed process to proc_pidpath.  The former was flakey, and the whole point of libproc is to protect us from potential flakiness at that level...

<rdar://problem/12594781>

llvm-svn: 167194

in the test output directory.

llvm-svn: 167193

Patch by Ashok Thirumurthi

llvm-svn: 167192

llvm-svn: 167191

Explicitly allow composition of null sub-register indices, and handle
that common case in an inlinable stub.

Use a compressed table implementation instead of the previous nested
switches which generated pretty bad code.

llvm-svn: 167190

llvm-svn: 167189

llvm-svn: 167188

No functionality change.

llvm-svn: 167187

(and the same for isFalse)

No functionality change.

llvm-svn: 167186

llvm-svn: 167185

llvm-svn: 167184

llvm-svn: 167183

llvm-svn: 167182

Nothing fancy, just a simple demonstration parser.

llvm-svn: 167181

  The adc/sbb optimization is to able to convert following expression
into a single adc/sbb instruction:
  (ult) ... = x + 1 // where the ult is unsigned-less-than comparison
  (ult) ... = x - 1

  This change is to flip the "x >u y" (i.e. ugt comparison) in order 
to expose the adc/sbb opportunity.

llvm-svn: 167180

llvm-svn: 167179

Thanks Ted.

llvm-svn: 167176

llvm-svn: 167175

llvm-svn: 167174

matching works correctly.
Part of rdar://12329974

llvm-svn: 167173

The stat cache became essentially useless ever since we started
validating all file entries in the PCH.
But the motivating reason for removing it now is that it also affected
correctness in this situation:

-You have a header without include guards (using "#pragma once" or #import)
-When creating the PCH:
  -The same header is referenced in an #include with different filename cases.
  -In the PCH, of course, we record only one file entry for the header file
  -But we cache in the PCH file the stat info for both filename cases

-Then the source files are updated and the header file is updated in a way that
 its size and modification time are the same but its inode changes

-When using the PCH:
  -We validate the headers, we check that header file and we create a file entry with its current inode
  -There's another #include with a filename with different case than the previously created file entry
  -In order to get its stat info we go through the cached stat info of the PCH and we receive the old inode
  -because of the different inodes, we think they are different files so we go ahead and include its contents.

Removing the stat cache will potentially break clients that are attempting to use the stat cache
as a way of avoiding having the actual input files available. If that use case is important, patches are welcome
to bring it back in a way that will actually work correctly (i.e., emit a PCH that is self-contained, coping with
literal strings, line/column computations, etc.).

This fixes rdar://5502805

llvm-svn: 167172

llvm-svn: 167171

llvm-svn: 167170

llvm-svn: 167168

Carlo Kok found an issue where default parameters were causing the wrong argument to be passed. I got rid of the default args so we don't run into this.

llvm-svn: 167167

cl is not attempting to complete a templated class when used in this
context. The conversion forces this to happen.

Thanks to Richard Smith for figuring this out.

llvm-svn: 167166

llvm-svn: 167165

llvm-svn: 167164