llvm-svn: 148239

llvm-svn: 148238

Committed as obvious

llvm-svn: 148237

llvm-svn: 148236

llvm-svn: 148235

llvm-svn: 148234

llvm-svn: 148233

A fix for the previous commit: "integer constant is too large for ‘long’ type" error on some 32-bit bots

llvm-svn: 148232

Adding a basic ELF dynamic loader and MC-JIT for ELF. Functionality is currently basic and will be enhanced with future patches.
Patch developed by Andy Kaylor and Daniel Malea. Reviewed on llvm-commits.

llvm-svn: 148231

llvm-svn: 148230

llvm-svn: 148229

Changed intrinsic ID operand to a target constant as its not used in any arithmetic so should not be checked in legalisation

llvm-svn: 148228

I think this is getting close on __dynamic_cast.  There's been quite a bit of code rearrangement, renaming, and better commenting.  This exercise has exposed and fixed a few more bugs.  I've also added several more tests (there's definitely a need for more tests here).

llvm-svn: 148227

We know that the blend instructions only use the MSB, so if the mask is
sign-extended then we can convert it into a SHL instruction. This is a
common pattern because the type-legalizer sign-extends the i1 type which
is used by the LLVM-IR for the condition.

Added a new optimization in SimplifyDemandedBits for SIGN_EXTEND_INREG -> SHL.

llvm-svn: 148225

class/Objective-C protocol suffices get all of the redeclarations of
that declaration wired to the definition, we no longer need to record
the identity of the definition in every declaration. Instead, just
record a bit to indicate whether a particular declaration is the
definition.

llvm-svn: 148224

protocol, record the definition pointer in the canonical declaration
for that entity, and then propagate that definition pointer from the
canonical declaration to all other deserialized declarations. This
approach works well even when deserializing declarations that didn't
know about the original definition, which can occur with modules.

A nice bonus from this definition-deserialization approach is that we
no longer need update records when a definition is added, because the
redeclaration chains ensure that the if any declaration is loaded, the
definition will also get loaded.

llvm-svn: 148223

chains, again. The prior implementation was very linked-list oriented, and
the list-splicing logic was both fairly convoluted (when loading from
multiple modules) and failed to preserve a reasonable ordering for the
redeclaration chains.

This new implementation uses a simpler strategy, where we store the
ordered redeclaration chains in an array-like structure (indexed based
on the first declaration), and use that ordering to add individual
deserialized declarations to the end of the existing chain. That way,
the chain mimics the ordering from its modules, and a bug somewhere is
far less likely to result in a broken linked list.

llvm-svn: 148222

llvm-svn: 148221

llvm-svn: 148220

llvm-svn: 148219

llvm-svn: 148218

llvm-svn: 148217

llvm-svn: 148216

Fixup for r148132. Type replacement for LoopsProperties: from DenseMap to std::map, since we need to keep a valid pointer to properties of current loop.

Message for r148132:
LoopUnswitch: All helper data that is collected during loop-unswitch iterations was moved to separated class (LUAnalysisCache).

llvm-svn: 148215

we're loading from the global array, not how it is spelled in the asm.
This should fix the MSVC bots.

llvm-svn: 148214

removal desired.

llvm-svn: 148213

re-computed rather than the variables be re-used just after the assert.
Just use the variables since we have them already. Fixes an unused
variable warning.

Also fix an 80-column violation.

llvm-svn: 148212

or Clang is using this, and it would be hard to use it correctly given
the thread hostility of the function. Also, it never checked the return
which is rather dangerous with chdir. If someone was in fact using this,
please let me know, as well as what the usecase actually is so that
I can add it back and make it more correct and secure to use. (That
said, it's never going to be "safe" per-se, but we could at least
document the risks...)

llvm-svn: 148211

Don't consider decltype(e) for an instantiation-dependent, but not
type-dependent, e to be non-type-dependent but canonical(!).

llvm-svn: 148210

not integer constant expressions. In passing, fix the 'folding is an extension'
diagnostic to not claim we're accepting the code, since that's not true in
-pedantic-errors mode, and add this diagnostic to -Wgnu.

llvm-svn: 148209

designator invalid. (Since we can't read the value of such a pointer, this only
affects the quality of diagnostics.)

llvm-svn: 148208

Change linkage computation so it doesn't depend on FunctionDecl::isExternC or VarDecl::isExternC, and instead queries what it actually cares about: whether the given declaration is inside an extern "C" context.  Fundamentally, figuring out whether a function/variable uses C linkage requires knowing the linkage, and the logic in FunctionDecl::isExternC and VarDecl::isExternC was getting it wrong.  Given that, fix FunctionDecl::isExternC and VarDecl::isExternC to use much simpler implementations that depend on the fixed linkage computation.

Fixes a regression to test/SemaCXX/linkage.cpp caused by a new warning exposing the fact that the internal state was wrong.

llvm-svn: 148207

llvm-svn: 148206

llvm-svn: 148205

Shrinks OverloadCandidate from 208 to 168 bytes.

llvm-svn: 148204

llvm-svn: 148202

Fixed two double "int close(int fd)" issues found by our file descriptor
interposing library on darwin:

The first is in SBDebugger::SetInputFileHandle (FILE *file, bool transfer_ownership)
where we would give our FILE * to a lldb_private::File object member variable and tell
it that it owned the file descriptor if "transfer_ownership" was true, and then we
would also give it to the communication plug-in that waits for stdin to come in and
tell it that it owned the FILE *. They would both try and close the file.

The seconds was when we use a file descriptor through ConnectionFileDescriptor 
where someone else is creating a connection with ConnectionFileDescriptor and a URL
like: "fd://123". We were always taking ownwership of the fd 123, when we shouldn't
be. There is a TODO in the comments that says we should allow URL options to be passed
to be able to specify this later (something like: "fd://123?transer_ownership=1"), but
we can get to this later.

llvm-svn: 148201

llvm-svn: 148200

should fix builds.

llvm-svn: 148199

Give OverloadCandidateSet the responsibility for destroying the implicit conversion sequences so we don't get double frees when the vector reallocates.

llvm-svn: 148198