reflect the migration in r171366.

Re-sort the #include lines to reflect the new paths.

llvm-svn: 171369

Removes a duplicate #include as well as cleaning up some sort order
regressions since I last ran the script over Clang.

llvm-svn: 171364

llvm-svn: 171350

directly.

This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.

llvm-svn: 171254

llvm-svn: 171184

Add intel_ocl_bicc calling convention as a function attribute to clang. The calling convention is already implemented in LLVM.

llvm-svn: 171056

llvm-svn: 171020

/// \param argBegin,argEnd the arguments to evaluate and pass to the constructor

llvm-svn: 171015

CGDecl.cpp: Prune three descriptions in two methods, CodeGenFunction::pushIrregularPartialArrayCleanup() and CodeGenFunction::pushRegularPartialArrayCleanup(). [-Wdocumentation]

/// \param array - a value of type elementType*
/// \param destructionKind - the kind of destruction required
/// \param initializedElementCount - a value of type size_t* holding the number of successfully-constructed elements

llvm-svn: 171013

llvm-svn: 171011

Reinstate r170806, reverted in r170835, with a fix use i1 instead of i8 for a value-initialized bool!

llvm-svn: 170837

Revert r170806, "Fix some bugs where we would sometimes use 0, not -1, when emitting a null constant of type pointer-to-data-member."

It broke stage2.

llvm-svn: 170835

When we are visiting the extern declaration of 'i' in

static int i = 99;
int foo() {
  extern int i;
  return i;
}

We should not try to handle it as if it was an function static. That is, we
must consider the written storage class.

Fixing this then exposes that the assert in EmitGlobalVarDeclLValue and the
if leading to its call are not completely accurate. They were passing before
because the second decl was marked as having external storage. I changed them
to check the linkage, which I find easier to understand.

Last but not least, there is something strange going on with cuda and opencl.
My guess is that the linkage computation for these languages needs to be
audited, but I didn't want to change that in this patch so I just updated
the storage classes to keep the current behavior.

Thanks to Reed Kotler for reporting this.

llvm-svn: 170827

Fix some bugs where we would sometimes use 0, not -1, when emitting a null constant of type pointer-to-data-member.

llvm-svn: 170806

llvm-svn: 170722

llvm-svn: 170721

Rename the 'Attributes' class to 'Attribute'. It's going to represent a single attribute in the future.

llvm-svn: 170500

Change DeclContextLookup(Const)Result to (Mutable)ArrayRef<NamedDecl*>, as per review discussion in r170365

This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).

Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)

llvm-svn: 170482

of assignment to a bool bitfield.  PR14638.

llvm-svn: 170480

llvm-svn: 170461

PR 14529 was opened because neither Clang or LLVM was expanding
calls to creal* or cimag* into instructions that just load the
respective complex field.  After some discussion, it was not
considered realistic to do this in LLVM because of the platform
specific way complex types are expanded.  Thus a way to solve
this in Clang was pursued.  GCC does a similar expansion.

This patch adds the feature to Clang by making the creal* and
cimag* functions library builtins and modifying the builtin code
generator to look for the new builtin types.

llvm-svn: 170455

llvm-svn: 170440

Add OpenCL images as clang builtin types.

llvm-svn: 170432

Revert changes from r170428, as I accidentally changed the line endings of these files to Windows style.

llvm-svn: 170431

llvm-svn: 170428

llvm-svn: 170425

llvm-svn: 170408

llvm-svn: 170403

to an object outside its lifetime does not have undefined behavior.

llvm-svn: 170387

llvm-svn: 170354

This reverts commit r170344. Doesn't even compile.

llvm-svn: 170351

llvm-svn: 170344

incompatibility with how complex values are returned.  It is sufficient
to flag all complex types as direct rather than indirect.

A new test case is provided that checks correct IR generation for the
various supported flavors of _Complex.

llvm-svn: 170302

Results in better block placement that helps close the
performance gap when making ubsan checks recoverable.

llvm-svn: 170263

llvm-svn: 170160

I wasn't sure where to put the test case for this, but this seemed like as good
a place as any. I had to reorder the tests here to make them legible while
still matching the order of metadata output in the IR file (for some reason
making it virtual changed the ordering).

Relevant commit to fix up LLVM to actually respect 'artificial' member
variables is coming once I write up a test case for it.

llvm-svn: 170154

bit-patterns which are not valid values for enumerated or boolean types.
These checks are the ubsan analogue of !range metadata.

llvm-svn: 170108

llvm-svn: 170100

My variadics patch, r169588, changed these calls to typically be
bitcasts rather than calls to a supposedly variadic function.
This totally subverted a hack where we intentionally dropped
excess arguments from such calls in order to appease the inliner
and a "warning" from the optimizer.  This patch extends the hack
to also work with bitcasts, as well as teaching it to rewrite
invokes.

llvm-svn: 170034

call sites as tail calls unconditionally.  While it's theoretically true that
this is just an optimization, it's an optimization that we very much want to
happen even at -O0, or else ARC applications become substantially harder to
debug.  See r169796 for the llvm/fast-isel side of things.
rdar://12553082

llvm-svn: 169996