In sections that are broken into atoms at symbols, if the first symbol in the
section is not at the start of the section, then make an anonymous atom for
the section content that is before the first symbol.

llvm-svn: 210142

This allows us to compile the following kind of code, which occurs in MSVC
headers:

  template <typename> struct S {
    __declspec(dllimport) static int x;
  };
  template <typename T> int S<T>::x;

The definition works similarly to a dllimport inline function definition and
gets available_externally linkage.

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

llvm-svn: 210141

llvm-svn: 210140

Previously each section kind had its own code to loop over the section and
parse it into atoms.  This refactoring has two tables.  The first maps sections
to ContentType.  The second maps ContentType to information on how to find 
the atom boundaries.  

A few bugs in test cases were discovered as part of the refactoring.  
No change in functionality intended.

llvm-svn: 210138

to the normal non-placement ::operator new and ::operator delete, but allow
optimizations like new-expressions and delete-expressions do.

llvm-svn: 210137

llvm-svn: 210135

This gets us closer to being able to remove LiveVariables entirely which is where dead instructions are currently tagged as such.

Reviewed by Jakob Olesen

llvm-svn: 210132

llvm-svn: 210130

Test case written by Dana Jansens.

llvm-svn: 210129

we know next time this happens.

llvm-svn: 210127

llvm-svn: 210126

llvm-svn: 210125

llvm-svn: 210124

It was able to parse

hidden dllexport global i32 42

but not

dllexport global i32 42

llvm-svn: 210121

llvm-svn: 210120

llvm-svn: 210119

llvm-svn: 210118

Without this patch, the testcase would fail on the delinearization of the second
array:

; void foo(long n, long m, long o, double A[n][m][o]) {
;   for (long i = 0; i < n; i++)
;     for (long j = 0; j < m; j++)
;       for (long k = 0; k < o; k++) {
;         A[i+3][j-4][k+7] = 1.0;
;         A[i][0][k] = 2.0;
;       }
; }

; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[3 + i0, -4 + i1, 7 + i2] };
; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };

Here is the output of FileCheck on the testcase without this patch:

; CHECK: [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[i0, 0, i2] };
         ^
<stdin>:26:2: note: possible intended match here
 [n, m, o] -> { Stmt_for_body6[i0, i1, i2] -> MemRef_A[o0] };
 ^

It is possible to find a good delinearization for A[i][0][k] only in the context
of the delinearization of both array accesses.

There are two ways to delinearize together all array subscripts touching the
same base address: either duplicate the code from scop detection to first gather
all array references and then run the delinearization; or as implemented in this
patch, use the same delinearization info that we computed during scop detection.

llvm-svn: 210117

Added set-memory:{content} and get-memory-address-hex: commands
to the test exe for gdb-remote.  Added a test that sets the content
via the inferior command line, then reads it back via gdb-remote
with $m.

Passing on debugserver.  Marked as fail on llgs.  Implementing
in the llgs branch next.

llvm-svn: 210116

Also revert r210096 which temporarily disabled the test while this was being
investigated.

llvm-svn: 210115

llvm-svn: 210114

[AArch64] Add regression tests for the load/store optimizer which cover post-index update folding with sub rather than add.

The tests check that the following transform happens:

  (ldr|str) X, [x20]
   ...
  sub x20, x20, #16
   ->
  (ldr|str) X, [x20], #-16

with X being either w0, x0, s0, d0 or q0.

llvm-svn: 210113

Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 210111

New code should probably use shared_ptr anyway.

llvm-svn: 210110

llvm-svn: 210109

llvm-svn: 210108

Thanks for David Blaikie for the suggestion.

llvm-svn: 210107

[asan] enable detect_odr_violation=2; https://code.google.com/p/address-sanitizer/wiki/OneDefinitionRuleViolation . This feature has been working quite well so far, found a few bugs and zero false positives. The main problem is that there could be lots of true positives and users will have to disable this checking until the bugs are fixed.

llvm-svn: 210106

Windows fix: Disable editline for MSVC. Since r208369 there have been issues, probably related to the editline wrapper. For now, it's more stable and usable disabled.

llvm-svn: 210105

Windows fix: Condition::Wait returned failure when it actually succeeded (SleepConditionVariableCS returns non-zero for success)

llvm-svn: 210104

llvm-svn: 210103

This means the output of LowerFormalArguments returns a lowered
SDValue with the correct type (expected in SelectionDAGBuilder).
Without this, an assertion under a DEBUG macro triggers when those
types are passed on the stack.

llvm-svn: 210102

This is a partial revert of r210075.

llvm-svn: 210101

llvm-svn: 210100

llvm-svn: 210099

dlopen()/dlclose() are not interceptable on Android,
so we update .sancov.map in module constructor callbacks.

llvm-svn: 210098

This fixes a few oddities when formatting multiple nested JavaScript
blocks, e.g.:

Before:
  promise.then(
      function success() {
        doFoo();
        doBar();
      },
      [], function error() {
        doFoo();
        doBaz();
      });
  promise.then([],
               function success() {
                 doFoo();
                 doBar();
               },
               function error() {
    doFoo();
    doBaz();
  });

After:
  promise.then(
      function success() {
        doFoo();
        doBar();
      },
      [],
      function error() {
        doFoo();
        doBaz();
      });
  promise.then([],
               function success() {
                 doFoo();
                 doBar();
               },
               function error() {
                 doFoo();
                 doBaz();
               });

llvm-svn: 210097

temporary disable part of a test because it causes clang to leak memory (want to have the sanitizer bot green)

llvm-svn: 210096

This patch implements semantic analysis to make sure that the loop is in OpenMP canonical form.
This is the form required for 'omp simd', 'omp for' and other loop pragmas.

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

llvm-svn: 210095

No functional changes.

llvm-svn: 210094