llvm_unreachable being reached in ARMConstantIslandPass, initializeFunctionInfo

[cmtice]

Bugzilla Link	31997
Resolution	FIXED
Resolved on	Feb 24, 2017 01:05
Version	trunk
OS	Linux
Blocks	#24719
Attachments	C file generated by clang driver for filing bug after clang crashed, .sh file generated by clang driver for filing bug after crash
CC	@cmtice,@kbeyls,@ostannard

Extended Description

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 = 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)

[cmtice]

assigned to @kbeyls

[cmtice]

Note: This was done with a slightly older version of LLVM, although we also saw this problem with ToT LLVM a few days ago.

To get the exact version we are using, use

lvm 285905 commit 77e7778
clang 285899 commit 47592b1815f5423fa708fca47741886043e6bb32

[cmtice]

This might be related to Bug # 30470; I'm not sure, but they look similar.

[kbeyls]

Should be fixed in r295964.