<html>
<head>
<base href="https://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 - Computation of locals' offsets is wrong when stack size exceeds 2G"
href="https://bugs.llvm.org/show_bug.cgi?id=49567">49567</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Computation of locals' offsets is wrong when stack size exceeds 2G
</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>All
</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: X86
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>simonas+llvm.org@kazlauskas.me
</td>
</tr>
<tr>
<th>CC</th>
<td>craig.topper@gmail.com, llvm-bugs@lists.llvm.org, llvm-dev@redking.me.uk, pengfei.wang@intel.com, spatel+llvm@rotateright.com
</td>
</tr></table>
<p>
<div>
<pre>Given the following test case:
; RUN: llc -O0 -mtriple=x86_64 < %s
; RUN: llc -O0 -mtriple=i686 < %s
%large = type [2148000000 x i8]
define void @banana() unnamed_addr #0 {
%1 = alloca %large, align 1
%2 = alloca %large, align 1
%3 = getelementptr inbounds %large, %large* %1, i64 0, i64 0
store i8 42, i8* %3, align 1
%4 = getelementptr inbounds %large, %large* %2, i64 0, i64 0
store i8 43, i8* %4, align 1
ret void
}
Will produce the following assembly:
movabsq $4295999872, %rax # imm = 0x1000FC180
subq %rax, %rsp
.cfi_def_cfa_offset 1032584
movb $42, -2146967424(%rsp)
movb $43, -128(%rsp)
movabsq $4295999872, %rax # imm = 0x1000FC180
addq %rax, %rsp
.cfi_def_cfa_offset 8
retq
You will notice that both the variables `alloca`d in this function are
considered to be below the already adjusted stack pointer, rather than above
it, where they ought to be.
This looks like a basic signed 32-bit integer overflow somewhere in
prologepilog:
# *** IR Dump Before Prologue/Epilogue Insertion & Frame Finalization
(prologepilog) ***:
# Machine code for function banana: NoPHIs, TracksLiveness, NoVRegs,
TiedOpsRewritten
Frame Objects:
fi#0: size=2148000000, align=1, at location [SP+8]
fi#1: size=2148000000, align=1, at location [SP+8]
bb.0 (%ir-block.0):
MOV8mi %stack.0, 1, $noreg, 0, $noreg, 42 :: (store 1 into %ir.3)
MOV8mi %stack.1, 1, $noreg, 0, $noreg, 43 :: (store 1 into %ir.4)
RET 0
# *** IR Dump After Prologue/Epilogue Insertion & Frame Finalization
(prologepilog) ***:
# Machine code for function banana: NoPHIs, TracksLiveness, NoVRegs,
TiedOpsRewritten
Frame Objects:
fi#0: size=2148000000, align=1, at location [SP-2148000000]
fi#1: size=2148000000, align=1, at location [SP-4296000000]
bb.0 (%ir-block.0):
$rax = frame-setup MOV64ri 4295999872
$rsp = SUB64rr $rsp(tied-def 0), $rax, implicit-def dead $eflags
CFI_INSTRUCTION def_cfa_offset 1032584
MOV8mi $rsp, 1, $noreg, -2146967424, $noreg, 42 :: (store 1 into %ir.3)
MOV8mi $rsp, 1, $noreg, -128, $noreg, 43 :: (store 1 into %ir.4)
$rax = frame-destroy MOV64ri 4295999872
$rsp = ADD64rr $rsp(tied-def 0), $rax, implicit-def dead $eflags
CFI_INSTRUCTION def_cfa_offset 8
RET 0
Worth noting that the the `def_cfa_offset` directive also overflowed in this
reproducer here.</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>