[llvm-bugs] [Bug 47050] New: 14 GB of storage and memory is not enough to build Clang 10
https://bugs.llvm.org/show_bug.cgi?id=47050 Bug ID: 47050 Summary: 14 GB of storage and memory is not enough to build Clang 10 Product: clang Version: 10.0 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: -New Bugs Assignee: unassignedclangb...@nondot.org Reporter: noloa...@gmail.com CC: htmldevelo...@gmail.com, llvm-bugs@lists.llvm.org, neeil...@live.com, richard-l...@metafoo.co.uk I'm working on Gentoo26 in a VM with 2 cores. The machine has 7.5 GB of free disk space, 2 GB of RAM and 4 GB of swap. The combined memory and storage is approximately 14 GB, but it is not enough to build Clang. 'emerge llvm clang' consistently fails even after 'rm -rf /var/tmp/*'. The tail of the build is: /usr/bin/x86_64-pc-linux-gnu-ar: lib64/libLLVMX86CodeGen.a: No space left on device ninja: build stopped: subcommand failed. * ERROR: sys-devel/llvm-10.0.0::gentoo failed (compile phase): * ninja -v -j3 -l0 failed ... I think something is really sideways here. There is an abundance of free space; but the build seems to be incredibly wasteful. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47051] New: ~(~X + Y) -> X - Y
https://bugs.llvm.org/show_bug.cgi?id=47051
Bug ID: 47051
Summary: ~(~X + Y) -> X - Y
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
LLVM should implement simplification ~(~X + Y) -> X - Y.
int bad (int x, int y)
{
return ~(~x + y);
}
Clang:
bad(int, int): # @bad(int, int)
not edi
lea eax, [rdi + rsi]
not eax
ret
GCC:
bad(int, int):
mov eax, edi
sub eax, esi
ret
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47052] New: _LIBCPP_DEBUG=1 causes link error
https://bugs.llvm.org/show_bug.cgi?id=47052
Bug ID: 47052
Summary: _LIBCPP_DEBUG=1 causes link error
Product: libc++
Version: 11.0
Hardware: PC
OS: Linux
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: unassignedclangb...@nondot.org
Reporter: jbulow-l...@jongel.net
CC: llvm-bugs@lists.llvm.org, mclow.li...@gmail.com
This program: (err1.cpp)
#include
int
main()
{
std::vector v;
return 0;
}
Compiled with:
clang++ -stdlib=libc++ -D_LIBCPP_DEBUG=1 -o err1 err1.cpp
Results in:
/tmp/err1-babb29.o: In function `void
std::__1::__libcpp_db::__insert_c > >(std::__1::vector
>*)':
err1.cpp:(.text._ZNSt3__111__libcpp_db10__insert_cINS_6vectorIiNS_9allocatorIiEEvPT_[_ZNSt3__111__libcpp_db10__insert_cINS_6vectorIiNS_9allocatorIiEEvPT_]+0x26):
undefined reference to `std::__1::__libcpp_db::__insert_c(void*,
std::__1::__c_node* (*)(void*, void*, std::__1::__c_node*))'
clang-12: error: linker command failed with exit code 1 (use -v to see
invocation)
Makefile:5: recipe for target 'err1' failed
make: *** [err1] Error 1
make: Target 'all' not remade because of errors.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47053] New: Missed opportunity to optimize pointer range checks
https://bugs.llvm.org/show_bug.cgi?id=47053
Bug ID: 47053
Summary: Missed opportunity to optimize pointer range checks
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Common Code Generator Code
Assignee: unassignedb...@nondot.org
Reporter: david.bolvan...@gmail.com
CC: llvm-bugs@lists.llvm.org
bool f1 (char *a, char *b)
{
return (a + 16 <= b) || (b + 16 <= a);
}
Clang:
f1(char*, char*): # @f1(char*, char*)
lea rax, [rdi + 16]
cmp rax, rsi
setbe cl
add rsi, 16
cmp rsi, rdi
setbe al
or al, cl
ret
GCC:
f1(char*, char*):
add rdi, 15
sub rdi, rsi
cmp rdi, 30
setaal
ret
GCC transforms
A + size <= B || B + size <= A
to
(size_t) (A + (size - 1) - B) > (size - 1) * 2
Could be useful to optimize better RT checks from vectorizer.
Godbolt: https://godbolt.org/z/9jsKa4
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 24758 in oss-fuzz: llvm:clangd-fuzzer: Stack-overflow in llvm::json::Parser::parseValue
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Reproducible Stability-Memory-MemorySanitizer Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-08-08 Type: Bug New issue 24758 by ClusterFuzz-External: llvm:clangd-fuzzer: Stack-overflow in llvm::json::Parser::parseValue https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24758 Detailed Report: https://oss-fuzz.com/testcase?key=5103658984013824 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clangd-fuzzer Job Type: libfuzzer_msan_llvm Platform Id: linux Crash Type: Stack-overflow Crash Address: 0x7ffe94419ff8 Crash State: llvm::json::Parser::parseValue Sanitizer: memory (MSAN) Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_msan_llvm&revision=202008070607 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5103658984013824 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47054] New: core.NullDereference despite field being assumed non-null with union-based type punning
https://bugs.llvm.org/show_bug.cgi?id=47054
Bug ID: 47054
Summary: core.NullDereference despite field being assumed
non-null with union-based type punning
Product: clang
Version: trunk
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: P
Component: Static Analyzer
Assignee: dcough...@apple.com
Reporter: aaronpuch...@alice-dsl.net
CC: dcough...@apple.com, llvm-bugs@lists.llvm.org
Created attachment 23831
--> https://bugs.llvm.org/attachment.cgi?id=23831&action=edit
Reproducer, compile with clang --analyze.
The attached code produces what I believe is a false positive. It starts here:
struct CommonData {
uint64_t* compilationMemSize = nullptr;
Heap* temp_heap = nullptr;
};
class Postprocessor {
public:
void run();
private:
shared_ptr m_commonData;
};
void Postprocessor::run()
{
auto data = m_commonData;
if (data->temp_heap)
*data->compilationMemSize = data->temp_heap->get_used_size();
}
then it goes into
uint64_t get_used_size() const
{
const frame_type* p = &first_frame;
uint64_t total_size = 0;
while (p && p!=last_frame)
{
total_size += p->size;
p = p->next;
}
return total_size + last_frame_usage;
}
where the check fires on the last line:
analyzer-bug.cpp:100:9: note: Assuming field 'temp_heap' is non-null
if (data->temp_heap)
^~~
analyzer-bug.cpp:100:5: note: Taking true branch
if (data->temp_heap)
^
analyzer-bug.cpp:101:37: note: Calling 'Heap::get_used_size'
*data->compilationMemSize = data->temp_heap->get_used_size();
^~~~
analyzer-bug.cpp:10:16: note: Assuming 'p' is null
while (p && p!=last_frame)
^
analyzer-bug.cpp:10:18: note: Left side of '&&' is false
while (p && p!=last_frame)
^
analyzer-bug.cpp:16:29: note: Access to field 'last_frame_usage' results in a
dereference of a null pointer
return total_size + last_frame_usage;
^~~~
Note that temp_heap is assumed as non-null, and p cannot be null in the first
iteration. The interesting part is the shared_ptr implementation, which uses
union-based type punning. Replacing this by reinterpret_cast or
__builtin_memcpy makes the issue disappear.
template class mem_conv
{
template union UCast {
U from_;
T to_;
constexpr explicit UCast(U x) noexcept : from_(x) {}
};
public:
template constexpr
static T cast(TM_FROM from) noexcept
{
static_assert(sizeof(TM_FROM) == sizeof(T));
UCast tmp(from);
return tmp.to_;
}
};
Now technically union-based type punning is not allowed according to the
standard, but I believe that Clang supports it.
The reproducer is still a bit large, but I wasn't able to reduce it further, it
seems that multiple things need to come together here.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47055] New: Incorrect codegen for enum with bool underlying type
https://bugs.llvm.org/show_bug.cgi?id=47055
Bug ID: 47055
Summary: Incorrect codegen for enum with bool underlying type
Product: clang
Version: unspecified
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: C++11
Assignee: unassignedclangb...@nondot.org
Reporter: aa...@aaronballman.com
CC: blitzrak...@gmail.com, dgre...@apple.com,
erik.pilking...@gmail.com, llvm-bugs@lists.llvm.org,
richard-l...@metafoo.co.uk
Consider the following code that appears to be valid C++11:
enum E : bool { Zero, One };
int f(int x) {
return (E)x;
}
Generates the following at -O0:
f(int): # @f(int)
pushrbp
mov rbp, rsp
mov dword ptr [rbp - 4], edi
mov eax, dword ptr [rbp - 4]
and al, 1
movzx eax, al
pop rbp
ret
We are ANDing x with 0x1 rather than comparing it against zero as required by
[conv.bool] and [expr.static.cast]p10.
--
You are receiving this mail because:
You are on the CC list for the bug.___
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47017] --wrap with a wrapper function from a DSO fails
https://bugs.llvm.org/show_bug.cgi?id=47017 Fangrui Song changed: What|Removed |Added Status|NEW |RESOLVED CC||i...@maskray.me Resolution|--- |FIXED --- Comment #1 from Fangrui Song --- Thanks, fixed by 99cd56906a4dd00db25b045eccddcb6802d39f8d [ELF] --wrap: set isUsedInRegularObj of __wrap_ if it is defined or shared I noticed another problem: in the new test in wrap-shlib-undefined.s, GNU ld does not add an undefined `bar` in .dynsym -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] Issue 24762 in oss-fuzz: llvm:clang-fuzzer: ASSERT: D.isPastIdentifier() && "Haven't past the location of the identifier yet?"
Status: New Owner: CC: k...@google.com, masc...@google.com, jdevlieg...@apple.com, igm...@gmail.com, d...@google.com, mit...@google.com, bigchees...@gmail.com, eney...@google.com, llvm-b...@lists.llvm.org, j...@chromium.org, v...@apple.com, mitchphi...@outlook.com, xpl...@gmail.com, akils...@apple.com Labels: ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Proj-llvm Reported-2020-08-08 Type: Bug New issue 24762 by ClusterFuzz-External: llvm:clang-fuzzer: ASSERT: D.isPastIdentifier() && "Haven't past the location of the identifier yet?" https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24762 Detailed Report: https://oss-fuzz.com/testcase?key=4854823409942528 Project: llvm Fuzzing Engine: libFuzzer Fuzz Target: clang-fuzzer Job Type: libfuzzer_asan_llvm Platform Id: linux Crash Type: ASSERT Crash Address: Crash State: D.isPastIdentifier() && "Haven't past the location of the identifier yet?" clang::Parser::ParseDirectDeclarator clang::Parser::ParseDeclaratorInternal Sanitizer: address (ASAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_asan_llvm&range=201712090607:201712100011 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4854823409942528 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43014] Reuse flags from xor; remove cmp
https://bugs.llvm.org/show_bug.cgi?id=43014 Craig Topper changed: What|Removed |Added Fixed By Commit(s)||44b260cb0aab387d85e4d59c16f ||c7b8866264f5e Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Craig Topper --- Should be fixed after 44b260cb0aab387d85e4d59c16fc7b8866264f5e -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47024] Use xor esi, esi instead of mov esi, 0
https://bugs.llvm.org/show_bug.cgi?id=47024 Craig Topper changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Fixed By Commit(s)||44b260cb0aab387d85e4d59c16f ||c7b8866264f5e --- Comment #5 from Craig Topper --- Threshold increased in 44b260cb0aab387d85e4d59c16fc7b8866264f5e -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 43014] Reuse flags from xor; remove cmp
https://bugs.llvm.org/show_bug.cgi?id=43014 Craig Topper changed: What|Removed |Added Fixed By Commit(s)|44b260cb0aab387d85e4d59c16f | |c7b8866264f5e | Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #4 from Craig Topper --- Oops I closed the wrong bug -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47056] New: --shuffle-sections can produce an invalid dynamic relocation order
https://bugs.llvm.org/show_bug.cgi?id=47056 Bug ID: 47056 Summary: --shuffle-sections can produce an invalid dynamic relocation order Product: lld Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P Component: ELF Assignee: unassignedb...@nondot.org Reporter: raf...@espindo.la CC: llvm-bugs@lists.llvm.org, smithp...@googlemail.com There are requirements on the order of dynamic relocations. For example, the IRELATIVE relocations must be after the regular ones. That is implemented by placing the synthetic sections in the right order. Unfortunately --shuffle-sections also shuffles those. The sortSection function should probably be updated to skip ELF_REL and ELF_RELA. -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47040] Assertion failed: isRegBase() && "Invalid base register access!"
https://bugs.llvm.org/show_bug.cgi?id=47040 Thomas Lively changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED Fixed By Commit(s)||cc612c29084e907900ce63ad903 ||1ab573a64e942 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 45757] line coverage shows coverage of comments
https://bugs.llvm.org/show_bug.cgi?id=45757 Zequan Wu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Zequan Wu --- Fixed in https://github.com/llvm/llvm-project/commit/b46176bbb094610460667edad950a9c99f844118 -- You are receiving this mail because: You are on the CC list for the bug.___ llvm-bugs mailing list llvm-bugs@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
[llvm-bugs] [Bug 47058] New: musttail emits wrong code for byval
https://bugs.llvm.org/show_bug.cgi?id=47058
Bug ID: 47058
Summary: musttail emits wrong code for byval
Product: libraries
Version: 10.0
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: X86
Assignee: unassignedb...@nondot.org
Reporter: yyc1...@gmail.com
CC: craig.top...@gmail.com, llvm-bugs@lists.llvm.org,
llvm-...@redking.me.uk, spatel+l...@rotateright.com
With the following IR:
```
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
%struct.A = type { i32, i32, i32, i32, i32, i32, i8*, i8*, i8*, i8*, i8*, i8*,
i8* }
define dso_local i32 @g(i32 %0, i32 %1, i32 %2, i8* %3, %struct.A*
byval(%struct.A) align 8 %4) local_unnamed_addr {
%6 = tail call i32 @k(i32 %0)
%7 = tail call i32 @f(i32 %0, i32 %1, i32 %2, i8* %3, %struct.A* nonnull
byval(%struct.A) align 8 %4)
ret i32 %7
}
declare i32 @k(i32)
declare i32 @f(i32, i32, i32, i8*, %struct.A* byval(%struct.A) align 8)
```
the emitted assembly with `llc` is (unwind info stripped out)
```
pushq %rbp
pushq %r15
pushq %r14
pushq %rbx
pushq %rax
movq%rcx, %r14
movl%edx, %r15d
movl%esi, %ebx
movl%edi, %ebp
callq k
movl%ebp, %edi
movl%ebx, %esi
movl%r15d, %edx
movq%r14, %rcx
addq$8, %rsp
popq%rbx
popq%r14
popq%r15
popq%rbp
jmp f # TAILCALL
```
which seems correct and is actually a tail call.
However, if `musttail` is used, i.e.
```
target datalayout =
"e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-pc-linux-gnu"
%struct.A = type { i32, i32, i32, i32, i32, i32, i8*, i8*, i8*, i8*, i8*, i8*,
i8* }
define dso_local i32 @g(i32 %0, i32 %1, i32 %2, i8* %3, %struct.A*
byval(%struct.A) align 8 %4) local_unnamed_addr {
%6 = tail call i32 @k(i32 %0)
%7 = musttail call i32 @f(i32 %0, i32 %1, i32 %2, i8* %3, %struct.A* nonnull
byval(%struct.A) align 8 %4)
ret i32 %7
}
declare i32 @k(i32)
declare i32 @f(i32, i32, i32, i8*, %struct.A* byval(%struct.A) align 8)
```
The code produced is then,
```
pushq %rbp
pushq %r15
pushq %r14
pushq %rbx
pushq %rax
movq%rcx, %r14
movl%edx, %r15d
movl%esi, %ebx
movl%edi, %ebp
callq k
leaq48(%rsp), %rsi
movl$10, %ecx
movq%rsp, %rdi
rep;movsq (%rsi), %es:(%rdi)
leaq48(%rsp), %rdi
movl$10, %ecx
movq%rsp, %rsi
rep;movsq (%rsi), %es:(%rdi)
movl%ebp, %edi
movl%ebx, %esi
movl%r15d, %edx
movq%r14, %rcx
addq$8, %rsp
popq%rbx
popq%r14
popq%r15
popq%rbp
jmp f # TAILCALL
```
which tries to copy 80 bytes of data from the argument memory onto 48 bytes of
reserved stack space that overwrites the saved register values as well as the
argument values before copying them back causing more damange..
This bug seems to be superficially similar to gcc's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96539 though gcc merely produced
inefficient code whereas the code produced here is wrong.
-
`llc -O0` (rather than the default optimization level) produces something worse
```
subq$56, %rsp
.cfi_def_cfa_offset 64
leaq64(%rsp), %rax
movl%edi, 52(%rsp) # 4-byte Spill
movq%rcx, 40(%rsp) # 8-byte Spill
movl%edx, 36(%rsp) # 4-byte Spill
movl%esi, 32(%rsp) # 4-byte Spill
movq%rax, 24(%rsp) # 8-byte Spill
callq k
movq%rsp, %rcx
movl$10, %r8d
movq%rcx, 16(%rsp) # 8-byte Spill
movq%r8, %rcx
movq16(%rsp), %rdi # 8-byte Reload
movq24(%rsp), %rsi # 8-byte Reload
rep;movsq (%rsi), %es:(%rdi)
leaq64(%rsp), %rdi
movq%r8, %rcx
movq16(%rsp), %rsi # 8-byte Reload
rep;movsq (%rsi), %es:(%rdi)
movl52(%rsp), %edi # 4-byte Reload
movl32(%rsp), %esi # 4-byte Reload
movl36(%rsp), %edx # 4-byte Reload
movq40(%rsp), %rcx # 8-byte Reload
movl%eax, 12(%rsp) # 4-byte Spill
addq$56, %rsp
.cfi_def_cfa_offset 8
jmp f # TAILCALL
```
which seems to got the source address for the first copy wrong, in addi
