| Issue |
204564
|
| Summary |
[AArch64] Miscompilation due to integer overflow in immediate offset for stack store/load instructions
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
simon902
|
## Description
In the AArch64 backend, a miscompilation occurs when a large memory offset overflows the immediate field of a stack store/load instruction in the prolog or epilog code.
In a Release build, this overflow happens silently. The compiler generates negative stack offsets in the final assembly that write below the stack pointer (corrupting memory).
In a **Debug** build, this is caught by the following assert in `AArch64FrameLowering.cpp`:
```cpp
assert((!RPI.isPaired() ||
(!RPI.isScalable() && RPI.Offset >= -64 && RPI.Offset <= 63) ||
(RPI.isScalable() && RPI.Offset >= -256 && RPI.Offset <= 255)) &&
"Offset out of bounds for LDP/STP immediate");
```
## Steps to reproduce
1. Compile the following C program (`bug.c`) with `clang -o bug bug.c`:
```c
__attribute__((preserve_all))
void trigger_stack_spill() {
asm volatile (
""
:
:
: "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7", "x8", "x9",
"x10", "x11", "x12", "x13", "x14", "x15", "x16", "x17", "x18",
"x19", "x20", "x21", "x22", "x23", "x24", "x25", "x26", "x27",
"x28", "x29", "x30",
"v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7", "v8", "v9",
"v10", "v11", "v12", "v13", "v14", "v15", "v16", "v17", "v18", "v19",
"v20", "v21", "v22", "v23", "v24", "v25", "v26", "v27", "v28", "v29",
"v30", "v31",
"memory", "cc"
);
}
int main() {
trigger_stack_spill();
return 0;
}
```
3. In the prolog (and epilog), the immediate overflows the 7-bit immediate for `stp` and wraps around, resulting in out-of-bounds negative stack offsets that corrupts memory:
```asm
stp x12, x11, [sp, #480]
stp x10, x9, [sp, #496]
stp x29, x30, [sp, #-512]
stp x28, x27, [sp, #-496]
stp x26, x25, [sp, #-480]
```
## Environment
**LLVM Version:** Reproduced on both `main` (commit: `f5b589e5cc500c3e10e02ed9ae2a275f6c7e3184`) and the `20.1.8` release.
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
