[llvm-bugs] [Bug 33568] New: DependenceAnalysis memory allocation crash

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=33568

            Bug ID: 33568
           Summary: DependenceAnalysis memory allocation crash
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Global Analyses
          Assignee: unassignedbugs at nondot.org
          Reporter: stanislav.manilov at gmail.com
                CC: llvm-bugs at lists.llvm.org

DependenceAnalysis results in a memory crash for the following code:

```
foo.c:
void f(int *A, int n) {
  int i, j;

  for (i = n - 1; i >= 0; i--) {
    for (j = i + 1; j < n; j++)
      A[j - 1] = A[j];
    A[j - 1] = n;
  }
}
```

With LLVM 3.9.1 the following results in a crash:

```
clang foo.c -c -emit-llvm -o foo.bc && opt -mem2reg -da -analyze foo.bc
```

The output is this:

```
Printing analysis 'Promote Memory to Register' for function 'f':
Pass::print not implemented for pass: 'Promote Memory to Register'!
Printing analysis 'Dependence Analysis' for function 'f':
da analyze - input [* *]!
da analyze - anti [* *|<]!
da analyze - anti [*|<]!
da analyze - output [* *]!
da analyze - *** Error in `opt': free(): invalid next size (fast):
0x0000000001d2e600 ***
```

If -mem2reg is not performed before -da there is no crash.

With LLVM trunk (f066646d) it seems that -mem2reg does not change the bitcode
for me (could be my bad setup) and thus initially I couldn't reproduce the
crash. So I generate the .ll code with LLVM 3.9 first like this:

```
clang foo.c -c -emit-llvm -o foo.bc && opt -mem2reg foo.bc -o foo.mem2reg.bc
```

And then after switching to LLVM trunk I do:

```
opt -da -analyze foo.mem2reg.bc
```

The output is this:

```
Printing analysis 'Dependence Analysis' for function 'f':
da analyze - input [* *]!
da analyze - anti [* *|<]!
da analyze - anti [*|<]!
da analyze - output [* *]!
da analyze -
```

where opt blocks (doesn't terminate, but it seems all CPUs are idle).

Here's foo.mem2reg.ll after disassembling:

```
; ModuleID = 'foo.mem2reg.bc'
source_filename = "foo.c"
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"

; Function Attrs: nounwind uwtable
define void @f(i32*, i32) {
  %3 = sub nsw i32 %1, 1
  br label %4

; <label>:4:                                      ; preds = %23, %2
  %.01 = phi i32 [ %3, %2 ], [ %24, %23 ]
  %5 = icmp sge i32 %.01, 0
  br i1 %5, label %6, label %25

; <label>:6:                                      ; preds = %4
  %7 = add nsw i32 %.01, 1
  br label %8

; <label>:8:                                      ; preds = %17, %6
  %.0 = phi i32 [ %7, %6 ], [ %18, %17 ]
  %9 = icmp slt i32 %.0, %1
  br i1 %9, label %10, label %19

; <label>:10:                                     ; preds = %8
  %11 = sext i32 %.0 to i64
  %12 = getelementptr inbounds i32, i32* %0, i64 %11
  %13 = load i32, i32* %12, align 4
  %14 = sub nsw i32 %.0, 1
  %15 = sext i32 %14 to i64
  %16 = getelementptr inbounds i32, i32* %0, i64 %15
  store i32 %13, i32* %16, align 4
  br label %17

; <label>:17:                                     ; preds = %10
  %18 = add nsw i32 %.0, 1
  br label %8

; <label>:19:                                     ; preds = %8
  %20 = sub nsw i32 %.0, 1
  %21 = sext i32 %20 to i64
  %22 = getelementptr inbounds i32, i32* %0, i64 %21
  store i32 %1, i32* %22, align 4
  br label %23

; <label>:23:                                     ; preds = %19
  %24 = add nsw i32 %.01, -1
  br label %4

; <label>:25:                                     ; preds = %4
  ret void
}
```

Tested bug on LLVM 3.9 on two different machines, tested trunk only on one
machine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170623/c57831f4/attachment-0001.html>