<base href="http://llvm.org/bugs/" />
<body><table border="1" cellspacing="0" cellpadding="8">
title="NEW --- - Miscompilation with lifetime markers and gc-annotated functions"
<td>Miscompilation with lifetime markers and gc-annotated functions
<pre>Created <span class=""><a href="attachment.cgi?id=10099" name="attach_10099" title="tarball with files and run script">attachment 10099</a> <a href="attachment.cgi?id=10099&action=edit" title="tarball with files and run script">[details]</a></span>
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).</pre>
<span>You are receiving this mail because:</span>
<li>You are on the CC list for the bug.</li>