llvm-svn: 72342

llvm-svn: 72341

llvm-svn: 72340

llvm-svn: 72339

llvm-svn: 72337

llvm-svn: 72336

llvm-svn: 72335

llvm-svn: 72333

llvm-svn: 72332

The DAGCombiner created a negative shiftamount, stored in an
unsigned variable. Later the optimizer eliminated the shift entirely as being
undefined.
Example: (srl (shl X, 56) 48). ShiftAmt is 4294967288.
Fix it by checking that the shiftamount is positive, and storing in a signed
variable.

llvm-svn: 72331

llvm-svn: 72330

llvm-svn: 72329

and it wasn't generating calls through @PLT for these functions.
hasLocalLinkage() is now false for available_externally,
I attempted to fix the inliner and dce to handle available_externally properly.
It passed make check.

llvm-svn: 72328

running an extra DAGCombine pass which improves the code a bit.

llvm-svn: 72326

will allow simplifying LegalizeDAG to eliminate type legalization.  (I 
have a patch to do that, but it's not quite finished; I'll commit it 
once it's finished and I've fixed any review comments for this patch.)  
See the comment at the beginning of 
lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp for more details on the
motivation for this patch.

llvm-svn: 72325

systems instead of attempting to promote them to a 64-bit SINT_TO_FP or 
FP_TO_SINT.  This is in preparation for removing the type legalization 
code from LegalizeDAG: once type legalization is gone from LegalizeDAG, 
it won't be able to handle the i64 operand/result correctly.

This isn't quite ideal, but I don't think any other operation for any 
target ends up in this situation, so treating this case specially seems 
reasonable.

llvm-svn: 72324

llvm-svn: 72315

llvm-svn: 72314

 - Otherwise we may incorrectly miss generation of some write barriers.

llvm-svn: 72313

llvm-svn: 72311

PPC double double.

(No testcase because no normal target uses the format at the moment.)

llvm-svn: 72310

llvm-svn: 72308

llvm-svn: 72304

expressions. We are now missing template instantiation logic for only
three classes of expressions:
  - Blocks-related expressions (BlockExpr, BlockDeclRefExpr)
  - C++ default argument expressions
  - Objective-C expressions

Additionally, our handling of DeclRefExpr is still quite poor, since
it cannot handle references to many kinds of declarations.

As part of this change, converted the TemplateExprInstantiator to use
iteration through all of the expressions via clang/AST/StmtNodes.def,
ensuring that we don't forget to add template instantiation logic for
any new expression node kinds.

llvm-svn: 72303

llvm-svn: 72301

Fix bug in FoldFCmp_IntToFP_Cst. If inttofp is a uintofp, use unsigned instead of signed integer constant.

llvm-svn: 72300

llvm-svn: 72299

llvm-svn: 72298

llvm-svn: 72293

llvm::SmallVector, using data() instead of &[0]. The PCH testsuite now
runs cleanly (again).

llvm-svn: 72292

ProtoRefs.data() instead of &ProtoRefs[0] to access the raw buffer.

llvm-svn: 72291

is true. Because of recent changes to llvm::SmallVector, using these iterators
when Exprs was empty would cause an assertion failure.

This fixes: PR 4245.

llvm-svn: 72286

must be dominated by the normal label.

llvm-svn: 72285

llvm-svn: 72284

non-argument names, pass the tokens through.

llvm-svn: 72283

call other member functions of class templates, including after
template instantiation. No functionality change.

llvm-svn: 72282

expressions. This change introduces another AST node,
CXXUnresolvedMemberExpr, that captures member references (x->m, x.m)
when the base of the expression (the "x") is type-dependent, and we
therefore cannot resolve the member reference yet.

Note that our parsing of member references for C++ is still quite
poor, e.g., we don't handle x->Base::m or x->operator int.

llvm-svn: 72281

llvm-svn: 72280

  (T(*)(int[x+y]));

is an (invalid) paren expression, but "x+y" will be parsed as part of the (rejected) type-id,
so unnecessary Action calls are made for an unused (and possibly leaked) "x+y".

Use a different scheme, similar to parsing inline methods. The parenthesized tokens are cached,
the context that follows is determined (possibly by parsing a cast-expression),
and then we re-introduce the cached tokens into the token stream and parse them appropriately.

llvm-svn: 72279

The TokenLexer may encounter annotations if the parser enters them using Preprocessor::EnterTokenStream.
So check for annotation before using the Token's IdentifierInfo.

llvm-svn: 72278