Steps to reproduce the bug:

1. Obtain the binary from this email.

The binary (along with the source) is free software, and is marked CC0
1.0. To view a copy of this mark, visit
https://creativecommons.org/publicdomain/zero/1.0/

2. Open this binary in radare2.

3. Run `aaa` for an analysis.

4. Run `pd 5 @ 0x400880`:

```
[0x00400940]> pd 5 @ 0x400880
│ 0x00400880 e18b03a9 stp x1, x2, [var_40h]
│ 0x00400884 e1430191 add x1, sp, 0x50
│ 0x00400888 e2c30091 add x2, sp, 0x30
│ 0x0040088c 200080d2 mov x0, 1
│ 0x00400890 e00b02a9 stp x0, x2, [var_20h]
```

5. Manually disassemble `e18b03a9` and `e00b02a9`, which can be done by
referring to <https://www.scs.stanford.edu/~zyedidia/arm64/stp_gen.html> and
extracting bits. `e00b02a9` disassembles to `stp x0, x2, [sp, #32]`, which
corresponds to what is given by radare2. However `e18b03a9` disassembles to
`stp x1, x2, [sp, #56]`, which does not (0x40 == 64 != 56).

6. To have a confirmation, go to that function to check whether `var_40h` is
indeed `sp+0x40`:

```
[0x00400940]> 0x400840
[0x00400840]> afv
arg const char * s @ x0
arg int64_t arg2 @ x1
var int64_t var_60h @ sp+0x0
var int64_t var_60h_2 @ sp+0x8
var int64_t var_10h @ sp+0x10
var int64_t var_20h @ sp+0x20
var int64_t var_20h_2 @ sp+0x28
var int64_t var_30h @ sp+0x30
var int64_t var_38h @ sp+0x38
var int64_t var_40h @ sp+0x40
var int64_t var_48h @ sp+0x48
var int64_t var_50h @ sp+0x50
var int64_t var_58h @ sp+0x58
```