https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120670
H.J. Lu <hjl.tools at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |go
Assignee|unassigned at gcc dot gnu.org |ian at airs dot com
--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
It looks like a libgo bug. libgo/runtime/go-memclr.c has
oid
memclrNoHeapPointers (void *p1, uintptr len)
{
#if !defined(__PPC64__)
__builtin_memset(p1, 0, len);
#else
...
#endif
}
On x86-64, memclrNoHeapPointers is compiled into __builtin_memset. With
-O2 -mmemset-strategy=vector_loop:256:noalign,libcall:-1:noalign
-minline-all-stringops
we got
...
movb $0, (%rax,%rdx)
movb $0, 1(%rax,%rdx)
addq $2, %rdx
cmpq %rsi, %rdx
jb .L5
...
When size == 8, we reached this loop and failed the test. If we do
# ifdef __x86_64__
if (len == 8)
{
volatile uint64 *vp = (volatile uint64*)(p1);
*vp = 0;
}
# endif
__builtin_memset(p1, 0, len);
the test passes. It looks like that memclrNoHeapPointers must clear a 8-byte
memory with a single 8-byte store, not with more than one stores.
