We previously mishandled UnresolvedUsingValueDecls in
NamedDecl::declarationReplaces, which caused us to forget decls
when there are multiple dependent using decls for the same name.

Fixes PR16936.

llvm-svn: 188737

llvm-svn: 188736

llvm-svn: 188735

llvm-svn: 188734

insertion of ObjC audit pragmas.

llvm-svn: 188733

Clang doesn't have a table mapping cl.exe to clang warnings.  While some
warnings like -Wsign-compare exist in both compilers, the majority do
not correspond and should usually be ignored.

llvm-svn: 188732

Website-only change.

llvm-svn: 188731

llvm-svn: 188730

This flag tells cl.exe to use up to n processes to compile the provided
source files.  I have no plans to implement this in clang.

llvm-svn: 188729

This adds a llvm.copysign intrinsic; We already have Libfunc recognition for
copysign (which is turned into the FCOPYSIGN SDAG node). In order to
autovectorize calls to copysign in the loop vectorizer, we need a corresponding
intrinsic as well.

In addition to the expected changes to the language reference, the loop
vectorizer, BasicTTI, and the SDAG builder (the intrinsic is transformed into
an FCOPYSIGN node, just like the function call), this also adds FCOPYSIGN to a
few lists in LegalizeVector{Ops,Types} so that vector copysigns can be
expanded.

In TargetLoweringBase::initActions, I've made the default action for FCOPYSIGN
be Expand for vector types. This seems correct for all in-tree targets, and I
think is the right thing to do because, previously, there was no way to generate
vector-values FCOPYSIGN nodes (and most targets don't specify an action for
vector-typed FCOPYSIGN).

llvm-svn: 188728

copysign/copysignf never become function calls (because the SDAG expansion code
does not lower to the corresponding function call, but rather directly
implements the associated logic), but copysignl almost always is lowered into a
call to the requested libm functon (and, thus, might clobber CTR).

llvm-svn: 188727

llvm-svn: 188726

llvm-svn: 188725

llvm-svn: 188724

llvm-svn: 188723

Reviewer: Eli
llvm-svn: 188722

llvm-svn: 188721

llvm-svn: 188720

llvm-svn: 188719

Fixes PR16931.

llvm-svn: 188718

llvm-svn: 188717

checking for missing parens in &&/|| expressions.

llvm-svn: 188716

llvm-svn: 188715

CF_IMPLICIT_BRIDGING_ENABLE/CF_IMPLICIT_BRIDGING_DISABLED
pair. wip.

llvm-svn: 188714

Also fix it calculating the wrong value. The struct index
is not a ConstantInt, so it was being interpreted as an array
index.

llvm-svn: 188713

llvm-svn: 188712

llvm-svn: 188711

Re-add the inboundsless tests I didn't add originally

llvm-svn: 188710

llvm-svn: 188709

Until gdb supports the new accelerator tables we should add the
pubnames section so that gdb_index can be generated from gold
at link time. On darwin we already emit the accelerator tables
and so don't need to worry about pubnames.

llvm-svn: 188708

Refactor the underlying code a bit to remove unnecessary calls to
"hasErrorOccurred" & make them consistently at all the entry points to
the IRGen ASTConsumer.

llvm-svn: 188707

instead of pointing to a page with two links on it.

llvm-svn: 188706

changing Parameter of Sema::ActOnCompoundStmt from MutableArrayRef to
ArrayRef.
No functionality change intended.

llvm-svn: 188705

llvm-svn: 188704

llvm-svn: 188703

Warning was:
  Argument not separated from preceding token by whitespace.

llvm-svn: 188701

The previous value was set to match some ancient version of Apple's GCC.
The value should be higher than anything used by Apple's GCC, but we don't
intend for this value to be updated in the future. We have other macros to
identify compiler versions. <rdar://problem/14749599>

llvm-svn: 188700

- split WidenVecRes_Binary into WidenVecRes_Binary and WidenVecRes_BinaryCanTrap
  - WidenVecRes_BinaryCanTrap preserves the original behaviour for operations
    that can trap
  - WidenVecRes_Binary simply widens the operation and improves codegen for
    3-element vectors by allowing widening and promotion on x86 (matches the
    behaviour of unary and ternary operation widening)
- use WidenVecRes_Binary for operations on integers.

Reviewed by: nrotem

llvm-svn: 188699

This means that "register read stmm0 --format f" actually works now.

This is a little messy but LLDB assumes 'long double' is portable, when it is not.

llvm-svn: 188698

llvm-svn: 188697