llvm-svn: 191272

llvm-svn: 191271

llvm-svn: 191270

llvm-svn: 191269

llvm-svn: 191268

the CFA instructions when it was profiling an -fomit-frame-pointer function
and a "volatile" register was saved on the stack (e.g. an argument register).
<rdar://problem/15036546>

llvm-svn: 191267

llvm-svn: 191266

1. Fixed constructor of shared clause.
2. Some macros for clauses processing are replaced by private template methods.
3. Additional checks in sema analysis of OpenMP clauses.

llvm-svn: 191265

Patch by Ana Pazos.

1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.

llvm-svn: 191264

Patch by Ana Pazos.

1.Added support for v1ix and v1fx types.
2.Added Scalar Pairwise Reduce instructions.
3.Added initial implementation of Scalar Arithmetic instructions.

llvm-svn: 191263

default-at-first-instruction UnwindPlan if we're at the beginning of a function and
the ABI can provide us with an UnwindPlan to get out of there before falling back
to the generic architectural default UnwindPlan (which usually assumes that the stack
has already been set up.)

Update the FuncUnwinders methods to gracefully handle the case where an assembly
profiler may not be available.

Fix a bug where FuncUnwinders::GetUnwindPlanArchitectureDefaultAtFunctionEntry was
returning the wrong UnwindPlan to its caller.

llvm-svn: 191262

llvm-svn: 191261

Sometimes a copy from a vreg -> vreg sneaks into the middle of a terminator
sequence. It is safe to slice this into the stack protector success bb.

This fixes PR16979.

llvm-svn: 191260

llvm-svn: 191259

PR17317.

llvm-svn: 191258

llvm-svn: 191257

llvm-svn: 191256

llvm-svn: 191255

llvm-svn: 191254

The order in which the comdat type unit sections appear in the output is
unspecified and may vary from machine to machine.

llvm-svn: 191253

The recursive nature of the address selection code can cause the stack to
explode if there is a long chain of GEPs. Convert the recursive bit into a
iterative method to avoid this.

<rdar://problem/12445434>

llvm-svn: 191252

gcc doesn't support "gcc -m sse" and this was not tested in clang and only
used for link argument on darwin, so this was very likely just a bug.

llvm-svn: 191251

This solves two problems:

1) MSBuild will not flag the build as unsuccessful just because we print
   an error in the output, since "error(clang):" doesn't seem to match
   the regex it's using.

2) It becomes more clear that the diagnostic is coming from clang as
   supposed to cl.exe.

Differential Revision: http://llvm-reviews.chandlerc.com/D1735

llvm-svn: 191250

This doesn't change a lot since clang still thinks it knows all of the
-f*, -m* and -W* options for example.

Other than the options clang explicitly claims to know, this fixes pr9701.

llvm-svn: 191249

This fix makes our headers consistent with gcc.

PR17312.

llvm-svn: 191248

We used to support both Windows and Unix style command line options. In Windows
style, an option and its value are separated by ":" (colon). In Unix, separator
is a space. Accepting both styles were convenient, but we can no longer allow
Unix style because I found that can be ambiguous.

For example, /nodefaultlib option takes an optional argument. In Windows style
it's going to be something like "/nodefaultlib:foo". There's no ambiguity what
"foo" means. However, if the option is "/nodefaultlib foo", "foo" can be
interpreted either an optional argument for "/nodefaultlib" or an input file
"foo.obj". We should just stop accepting the non-standard command line style.

llvm-svn: 191247

llvm-svn: 191246

llvm-svn: 191245

llvm-svn: 191244

While I'm here, also fix the alignment computation for the whole family of
intrinsics.

PR17298.

llvm-svn: 191243

This is not to say this is the desired behavior, but it makes sure we notice
if it changes.

llvm-svn: 191242

The underlying type of all plain enums in MSVC is 'int', even if the
enumerator contains large 32-bit unsigned values or values greater than
UINT_MAX.  The only way to get a large or unsigned enum type is to
request it explicitly with the C++11 strong enum types feature.

However, since LLVM isn't C++11 yet, I had to add a conditional
LLVM_ENUM_INT_TYPE to Compiler.h to control its usage.

The motivating true positive for this change is compiling PointerIntPair
with MSVC for win64.  The PointerIntMask value is supposed to be pointer
sized value of all ones with some low zeros.  Instead, it's truncated to
32-bits!  We are only saved later because it is sign extended back in
the AND with int64_t, and we happen to want all ones.

This silences lots of -Wmicrosoft warnings during a clang self-host
targeting Windows.

llvm-svn: 191241

use Cocoa's naming convention for properties of ObjC
object type. // rdar://15045005

llvm-svn: 191240

checking patch until we get full dumping support.

llvm-svn: 191239

llvm-svn: 191238

llvm-svn: 191237

llvm-svn: 191236

llvm-svn: 191235

llvm-svn: 191234

llvm-svn: 191233