llvm-svn: 233536

llvm-svn: 233535

llvm-svn: 233534

llvm-svn: 233533

If input relocation records have RELA format while output dynamic
relocations have REL format the only way to transfer a dynamic
relocation addendum is to save it into the location modified by
the dynamic relocation.

llvm-svn: 233532

Differential revision: http://reviews.llvm.org/D8454

llvm-svn: 233531

Before:
  goog.scope(function() {
  // test
  var x = 0;
  // test
  });

After:
  goog.scope(function() {
  // test
  var x = 0;
    // test
  });

llvm-svn: 233530

This leads to terribly slow compile times under MSAN. More discussion
on the commit thread of r233447.

llvm-svn: 233529

see comments http://reviews.llvm.org/D6835

llvm-svn: 233528

by Asaf Badouh (asaf.badouh@intel.com)

llvm-svn: 233525

[X86] In getHostCPUFeatures, disable xop, f16c, fma, and fma4 if OS does not support saving ymm state.

llvm-svn: 233518

[X86] Remove FeatureAES for 'corei7' CPU. 'corei7' should match 'nehalem' which doesn't have AES. Having AES and not PCLMUL makes 'corei7' halfway between Nehalem and Westmere.

llvm-svn: 233517

[X86] Use the more specific CPU names like 'nehalem', 'westmere', 'haswell', etc. Split Nehalem and Westmere CPUs.

llvm-svn: 233516

llvm-svn: 233515

llvm-svn: 233514

Adds atomic update codegen for the following forms of expressions:

x binop= expr;
x++;
++x;
x--;
--x;
x = x binop expr;
x = expr binop x;
If x and expr are integer and binop is associative or x is a LHS in a RHS of the assignment expression, and atomics are allowed for type of x on the target platform atomicrmw instruction is emitted.
Otherwise compare-and-swap sequence is emitted:

bb:
...
atomic load <x>
cont:
<expected> = phi [ <x>, label %bb ], [ <new_failed>, %cont ]
<desired> = <expected> binop <expr>
<res> = cmpxchg atomic &<x>, desired, expected
<new_failed> = <res>.field1;
br <res>field2, label %exit, label %cont
exit:
...

Differential Revision: http://reviews.llvm.org/D8536

llvm-svn: 233513

Summary: In dumpMemorySections a cast was too short, and in resolveRelocations a format string was too short.

Test Plan:
Enable debug build and run a program which invokes MCJIT::finalizeObject(). Saw valid input as below (highlighted addresses were previously truncated):

```
Parse relocations:
Resolving relocations Section #0	**0x7f4c1337b000**
----- Contents of section socket1 before relocations -----
**0x00007f4c1337b000**: 18 01 00 00 01 01 01 0a 00 00 00 00 04 03 02 01
0x00007f4c1337b010: 7b 1a f8 ff 00 00 00 00 18 11 00 00 05 00 00 00

```

Reviewers: lhames

Reviewed By: lhames

Subscribers: llvm-commits, ast

Differential Revision: http://reviews.llvm.org/D8681

llvm-svn: 233512

Replace boolean IsExplicit parameter of OpenMPRuntime::emitBarrierCall() method by OpenMPDirectiveKind Kind for better compatibility with the runtime library. Also add processing of 'nowait' clause on worksharing directives.
Differential Revision: http://reviews.llvm.org/D8659

llvm-svn: 233511

llvm-svn: 233510

MCJIT.

This patch decouples the two responsibilities of the RTDyldMemoryManager class,
memory management and symbol resolution, into two new classes:
RuntimeDyld::MemoryManager and RuntimeDyld::SymbolResolver.

The symbol resolution interface is modified slightly, from:

  uint64_t getSymbolAddress(const std::string &Name);

to:

  RuntimeDyld::SymbolInfo findSymbol(const std::string &Name);

The latter passes symbol flags along with symbol addresses, allowing RuntimeDyld
and others to reason about non-strong/non-exported symbols.


The memory management interface removes the following method:

  void notifyObjectLoaded(ExecutionEngine *EE,
                          const object::ObjectFile &) {}

as it is not related to memory management. (Note: Backwards compatibility *is*
maintained for this method in MCJIT and OrcMCJITReplacement, see below).


The RTDyldMemoryManager class remains in-tree for backwards compatibility.
It inherits directly from RuntimeDyld::SymbolResolver, and indirectly from
RuntimeDyld::MemoryManager via the new MCJITMemoryManager class, which
just subclasses RuntimeDyld::MemoryManager and reintroduces the
notifyObjectLoaded method for backwards compatibility).

The EngineBuilder class retains the existing method:

  EngineBuilder&
  setMCJITMemoryManager(std::unique_ptr<RTDyldMemoryManager> mcjmm);

and includes two new methods:

  EngineBuilder&
  setMemoryManager(std::unique_ptr<MCJITMemoryManager> MM);

  EngineBuilder&
  setSymbolResolver(std::unique_ptr<RuntimeDyld::SymbolResolver> SR);

Clients should use EITHER:

A single call to setMCJITMemoryManager with an RTDyldMemoryManager.

OR (exclusive)

One call each to each of setMemoryManager and setSymbolResolver.

This patch should be fully compatible with existing uses of RTDyldMemoryManager.
If it is not it should be considered a bug, and the patch either fixed or
reverted.

If clients find the new API to be an improvement the goal will be to deprecate
and eventually remove the RTDyldMemoryManager class in favor of the new classes.

llvm-svn: 233509

Method CXXMethodDecl::isStaticOverloadedOperator expects Operator field
from the struct OperatorFunctionId, which is a member of the union in
the class UnqualifiedId. If the kind of UnqualifiedId is not checked,
there is no guarantee that the value that this method receives will be
correct, because it can be the value of another union member and not
OperatorFunctionId.

This bug manifests itself when running make check-all on mips64 BE. 

This fix resolves the following regression tests: 
Clang :: CXX/special/class.dtor/p9.cpp
Clang :: CodeGenCXX/2006-09-12-OpaqueStructCrash.cpp
Clang :: CodeGenCXX/ctor-dtor-alias.cpp
Clang :: CodeGenCXX/debug-info-windows-dtor.cpp
Clang :: CodeGenCXX/dllexport-members.cpp
Clang :: CodeGenCXX/dllexport.cpp

Patch by Violeta Vukobrat.

Differential Revision:  http://reviews.llvm.org/D8437

llvm-svn: 233508

This simplifies already one test case and is needed for upcoming improvements
to our delinearization.

llvm-svn: 233507

llvm-svn: 233506

Reported-by: http://buildd-clang.debian.net/scan-build
llvm-svn: 233505

Add convenience function for building a typed IR Constant from trampoline
addresses.
   

llvm-svn: 233504

Utilizing IMAGEREL relocations for synthetic IR constructs isn't
valuable, just clutter.  While we are here, simplify HandlerType names
by making the numeric value for the 'adjective' part of the mangled name
instead of appending '.const', etc.  The old scheme made for very long
global names and leads to wordy things like '.std_bad_alloc'

llvm-svn: 233503

llvm-svn: 233502

  This will strip the constant factor of a parameter befor we add it to
  the SCoP. As a result the access functions are simplified, e.g., for
  the attached test case.

llvm-svn: 233501

They're harmless and it's easy to generate them from clang, leading to
a crash in LLVM. Found by afl-fuzz.

llvm-svn: 233500

Found by afl-fuzz.

llvm-svn: 233499

llvm-svn: 233498

ExpandBuiltinMacro would strip the identifier and downstream users crash
when they encounter an identifier token with nullptr identifier info.

Found by afl-fuzz.

llvm-svn: 233497

The buffer is guaranteed to be zero-terminated so we can just
circumvent the check. Found by afl-fuzz.

llvm-svn: 233496

llvm-svn: 233495

Otherwise it stays uninitialized with potentially catastrophic results.
Found by afl-fuzz.

llvm-svn: 233494

It will crash downstream somewhere. Found by afl-fuzz.

llvm-svn: 233493

Found by clang-fuzz.

llvm-svn: 233492

While dereferencing ThisTokEnd is fine and we know that it's not in
[a-zA-Z0-9_.], ThisTokEnd[1] is really past the end.

Found by asan and with a little help from clang-fuzz.

llvm-svn: 233491

We know that the last accessible char is not in [a-zA-Z0-9_.] so we can
happily scan on as long as it is. No functionality change.

llvm-svn: 233490

By Asaf Badouh (asaf.badouh@intel.com)

llvm-svn: 233489