llvm-svn: 112200

behavior in C than in C++ (which is what the original test case was).

llvm-svn: 112199

llvm-svn: 112198

llvm-svn: 112197

it might previously have been a tag TST.

llvm-svn: 112196

encodable as a 16-bit wide instruction.

llvm-svn: 112195

typed-text blocks into one of each.

llvm-svn: 112194

function, take into account the qualifiers on the object argument
(e.g., what will become "this"), filtering around uncallable member
functions and giving a slight priority boost to those with
exactly-matching qualifiers.

llvm-svn: 112193

llvm-svn: 112192

llvm-svn: 112191

fix: add a flag to MapValue and friends which indicates whether
any module-level mappings are being made. In the common case of
inlining, no module-level mappings are needed, so MapValue doesn't
need to examine non-function-local metadata, which can be very
expensive in the case of a large module with really deep metadata
(e.g. a large C++ program compiled with -g).

This flag is a little awkward; perhaps eventually it can be moved
into the ClonedCodeInfo class.

llvm-svn: 112190

llvm-svn: 112189

llvm-svn: 112188

clang-interpreter: libFrontend depends on libSerialization. Fix linux build by changing the link order.

llvm-svn: 112187

llvm-svn: 112186

Do unsigned char comparisons in StringRef::compare_lower to be more consistent with compare in corner cases.

llvm-svn: 112185

llvm-svn: 112184

llvm-svn: 112183

llvm-svn: 112182

llvm-svn: 112181

into the clients, e.g., the printing code-completion consumer and
c-index-test. Clients may want to re-sort the results anyway.

Provide a libclang function that sorts the results.

3rd try. How embarrassing.

llvm-svn: 112180

llvm-svn: 112179

llvm-svn: 112178

It still depends on Type because DeclarationName.h does.

llvm-svn: 112177

comparison with 0. These two pieces of code should give identical results:

  rsbs r1, r1, 0
  cmp  r0, r1
  mov  r0, #0
  it   ls
  mov  r0, #1

and:

  cmn  r0, r1
  mov  r0, #0
  it   ls
  mov  r0, #1

However, the CMN gives the *opposite* result when r1 is 0. This is because the
carry flag is set in the CMP case but not in the CMN case. In short, the CMP
instruction doesn't perform a truncate of the (logical) NOT of 0 plus the value
of r0 and the carry bit (because the "carry bit" parameter to AddWithCarry is
defined as 1 in this case, the carry flag will always be set when r0 >= 0). The
CMN instruction doesn't perform a NOT of 0 so there is never a "carry" when this
AddWithCarry is performed (because the "carry bit" parameter to AddWithCarry is
defined as 0).

The AddWithCarry in the CMP case seems to be relying upon the identity:

  ~x + 1 = -x

However when x is 0 and unsigned, this doesn't hold:

   x = 0
  ~x = 0xFFFF FFFF
  ~x + 1 = 0x1 0000 0000
  (-x = 0) != (0x1 0000 0000 = ~x + 1)

Therefore, we should disable *all* versions of CMN, especially when comparing
against zero, until we can limit when the CMN instruction is used (when we know
that the RHS is not 0) or when we have a hardware fix for this.

(See the ARM docs for the "AddWithCarry" pseudo-code.)

This is related to <rdar://problem/7569620>.

llvm-svn: 112176

llvm-svn: 112175

llvm-svn: 112174

don't currently need the bits anyway.

llvm-svn: 112173

on random hosts, lets see!

llvm-svn: 112172

llvm-svn: 112171

llvm-svn: 112170

llvm-svn: 112169

apparently try to support.

llvm-svn: 112168

path and ...", it is failing tests.

llvm-svn: 112161

doth lay upon the chopping block.

llvm-svn: 112160

llvm-svn: 112159

except ...", it is causing *massive* performance regressions when building Clang
with itself (-O3 -g).

llvm-svn: 112158

individual ...", which depends on r111922, which I am reverting.

llvm-svn: 112157

This lets us remove Sema.h's dependency on Expr.h and Decl.h.

llvm-svn: 112156

llvm-svn: 112155