https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68601
Bug ID: 68601
Summary: GCC miscompiles LLVM on Windows
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kfischer at college dot harvard.edu
Target Milestone: ---
I am compiling LLVM on Windows using Mingw-w64's pre-built GCC 5.2.0 for MSYS2
and believe the generated code is invalid. The effect of this miscompilation is
an LLVM assertion firing even though it's conditions is not satisfied. This
does not occur with -O0 and I have verified in the debugger that the memory
looks as expected.
The C++ code in questions (from LLVM's Instructions.cpp is):
```
assert(getOperand(0)->getType() ==
cast<PointerType>(getOperand(1)->getType())->getElementType()
&& "Ptr must be a pointer to Val type!");
```
Here is the relevant disassembly as seen from GDB:
```
│0x1a6b990 <llvm::StoreInst::AssertOK()+80> mov -0x18(%rbx),%rcx
│
│0x1a6b994 <llvm::StoreInst::AssertOK()+84> callq 0x1bbf360
<llvm::cast_or_null<llvm::Value, llvm::Value>(llvm::Value*)> │
│0x1a6b999 <llvm::StoreInst::AssertOK()+89> mov 0x8(%rax),%rdx
│
│0x1a6b99d <llvm::StoreInst::AssertOK()+93> mov -0x30(%rbx),%rcx
│
│0x1a6b9a1 <llvm::StoreInst::AssertOK()+97> callq 0x1bbf360
<llvm::cast_or_null<llvm::Value, llvm::Value>(llvm::Value*)> │
│0x1a6b9a6 <llvm::StoreInst::AssertOK()+102> mov %rdx,%rcx
│
│0x1a6b9a9 <llvm::StoreInst::AssertOK()+105> mov 0x8(%rax),%rsi
│
>│0x1a6b9ad <llvm::StoreInst::AssertOK()+109> callq 0x1c60420
<llvm::cast<llvm::PointerType, llvm::Type>(llvm::Type*)> │
│0x1a6b9b2 <llvm::StoreInst::AssertOK()+114> mov 0x10(%rax),%rax
│
│0x1a6b9b6 <llvm::StoreInst::AssertOK()+118> cmp (%rax),%rsi
```
It seems live the mov at +102 is moving a junk value (since the previous call
clobbers rdx). Moreover, before the call %rdx had value
`getOperand(1)->getType()`, which would be the correct thing to put into rcx
here. I thus think the compiler got confused and didn't notice that the
register is being clobbered by the call.
The full pre-processed source is attached.
