[LLVMbugs] [Bug 15376] New: Miscompilation with lifetime markers and gc-annotated functions
bugzilla-daemon at llvm.org
bugzilla-daemon at llvm.org
Wed Feb 27 07:15:48 PST 2013
Bug ID: 15376
Summary: Miscompilation with lifetime markers and gc-annotated
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: eschew at gmail.com
CC: llvmbugs at cs.uiuc.edu
Created attachment 10099
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
* 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
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...
More information about the llvm-bugs