<html>
<head>
<base href="http://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - llvm_unreachable being reached in ARMConstantIslandPass, initializeFunctionInfo"
href="http://bugs.llvm.org/show_bug.cgi?id=31997">31997</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>llvm_unreachable being reached in ARMConstantIslandPass, initializeFunctionInfo
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: ARM
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>cmtice@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=18003" name="attach_18003" title="C file generated by clang driver for filing bug after clang crashed">attachment 18003</a> <a href="attachment.cgi?id=18003&action=edit" title="C file generated by clang driver for filing bug after clang crashed">[details]</a></span>
C file generated by clang driver for filing bug after clang crashed
The switch statements in initializeFunctionInfo, in ARMConstantPass.cpp are
supposed to handle all the ARM opcodes, but do not handle t2LDRBpci
This causes execution to reach the 'llvm_unreachable' statement at line 755,
(the default case in the 'switch (Opc)' statment) in
ARMCOnstantIslands::initializeFunctionInfo, in ARMConstantIslandPass.cpp.
We found this bug by compiling pam_handlers.c -- we were seeing some very odd
behavior out of the compiler when compiling that file. After spending some
time tracking it down, we narrowed it down to: the Opc is NOT recognized by the
switch statement, so it goes to the default case (llvm_unreachable), which does
nothing in a Release build, but which caused unexpected/undefined behavior in
the rest of the compilation.
We verified that this was what was happening by replacing that llvm_unreachable
statement with 'abort();'. This results in a crash when compiling
pam_handlers.c
I am attaching the two files the clang driver created, for filing bugs, when
the crash occurred.
We also examined the crash site in gdb, which is how we found the exact opcode
that is not being handled:
Breakpoint 1, 0x00007ffff0759940 in abort () from /lib64/libc.so.6
(gdb) bt
#0 0x00007ffff0759940 in abort () from /lib64/libc.so.6
#1 0x00007ffff43dba4c in (anonymous
namespace)::ARMConstantIslands::initializeFunctionInfo (this=0x59a4d70,
CPEMIs=...)
at
/var/tmp/portage/sys-devel/llvm-4.0_pre285905-r3/work/llvm-4.0_pre285905/lib/Target/ARM/ARMConstantIslandPass.cpp:756
#2 0x00007ffff43d9e2d in (anonymous
namespace)::ARMConstantIslands::runOnMachineFunction (this=0x59a4d70, mf=...)
at
/var/tmp/portage/sys-devel/llvm-4.0_pre285905-r3/work/llvm-4.0_pre285905/lib/Target/ARM/ARMConstantIslandPass.cpp:372
#3 0x00007ffff2d1d77a in llvm::MachineFunctionPass::runOnFunction (
this=0x59a4d70, F=...)
at
/var/tmp/portage/sys-devel/llvm-4.0_pre285905-r3/work/llvm-4.0_pre285905/lib/CodeGen/MachineFunctionPass.cpp:62
#4 0x00007ffff2aa004d in llvm::FPPassManager::runOnFunction (this=0x5988ed0,
F=...)
at
/var/tmp/portage/sys-devel/llvm-4.0_pre285905-r3/work/llvm-4.0_pre285905/lib/IR/LegacyPassManager.cpp:1509
#5 0x00007ffff2aa0213 in llvm::FPPassManager::runOnModule (this=0x5988ed0,
M=...)
at
/var/tmp/portage/sys-devel/llvm-4.0_pre285905-r3/work/llvm-4.0_pre285905/lib/IR/LegacyPassManager.cpp:1530
...
(gdb) up
#1 0x00007ffff43dba4c in (anonymous
namespace)::ARMConstantIslands::initializeFunctionInfo (this=0x59a4d70,
CPEMIs=...)
at
/var/tmp/portage/sys-devel/llvm-4.0_pre285905-r3/work/llvm-4.0_pre285905/lib/Target/ARM/ARMConstantIslandPass.cpp:756
756 abort();
(gdb) list
751 bool IsSoImm = false;
752
753 switch (Opc) {
754 default:
755 //llvm_unreachable("Unknown addressing mode for CP
reference!");
756 abort();
757
758 // Taking the address of a CP entry.
759 case ARM::LEApcrel:
760 case ARM::LEApcrelJT:
(gdb) print Opc
$1 = 2645
(gdb) print I.dump()
%R0<def> = t2LDRBpci <cp#1>, pred:14, pred:%noreg; mem:LD1[getelementptr
inbounds ([2 x i8], [2 x i8]* @.str.53, i32 0, i32 0)]
dbg:../../../../../../../../usr/armv7a-cros-linux-gnueabi/usr/include/bits/string3.h:99:10
@[ pam_handlers.c:741:11 ]
$2 = void
(gdb)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>