[LLVMbugs] [Bug 15376] New: Miscompilation with lifetime markers and gc-annotated functions

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=15376

            Bug ID: 15376
           Summary: Miscompilation with lifetime markers and gc-annotated
                    functions
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: eschew at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10099
  --> http://llvm.org/bugs/attachment.cgi?id=10099&action=edit
tarball with files and run script

I believe I have found a bug in the interaction of four LLVM features:

  * lifetime markers with multiple disjoint ranges
  * gc annotations on functions
  * inlining
  * loop rotation

I've attached several IR files in a tarball to document what I've found:

  * pre.combined.minmin.ocamlgc.ll is the "base" file;
    it can be compiled and run with llc + g++, and prints "89" when run.

    Of note, it contains exactly two functions with lifetime annotations,
    and each function has lifetime annotations on only a single alloca.
    The caller has three non-overlapping live ranges, and the callee
    has a single basic block with a single live range.

    Also, the functions in this module are annotated with 'gc "ocaml"',
    though no gc intrinsics are used.

  * Running opt on pre.combined.mimmin.ocamlgc.ll with passes
      -basicaa -inline -functionattrs -instcombine -loop-rotate -gvn
    yields man.combined.minmin.ocamlgc.ll, which segfaults when run.

    This appears to be due to a stack slot being used for storing
    (essentially) values of type **i64 and *i64; the crash occurs
    when doubly-dereferencing a pointer-to-integer.

  * Removing the lifetime markers from the callee (in pre...)
    avoids the bug, as does merging any two adjacent lifetimes
    in the caller.

  * The generated code contains two instances where lifetimes
    are directly adjacent, i.e. the code has the following insn sequence:

      call void @llvm.lifetime.end(i64 -1, i8* %0)
      call void @llvm.lifetime.start(i64 -1, i8* %0)

    Commenting out either of these pairs avoids the bug.

  * pre.combined.minmin.nogc.ll is pre.combined.minmin.ocamlgc.ll
    with all the gc annotations stripped.

  * Running opt with the same set of passes on on pre...nogc.ll
    does not trigger the bug.

  * Running bugpoint on pre.combined.mimmin.ocamlgc.ll will
nondeterministically
    blame the -loop-rotate or -inline passes (or a larger set of passes
    containing these two), corresponding to the files
    fails-with-inline.ll and fails-with-loop-rotate.ll. Applying the
    appropriate transformation to either file will trigger the bug.
    Interestingly, the gc annotations can be stripped from these files,
    and the bug will still be triggered.

This behavior occurs on both LLVM 3.2 and tip of trunk (r176171),
when generating 32-bit code (don't have a machine to test with 64-bit).

-- 
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/20130227/7c7542c8/attachment.html>