On Fri, Jan 17, 2025 at 12:07 AM Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> wrote: > > Paul Eggert wrote: > > > ../lib/crc-x86_64-pclmul.c:120:26: runtime error: load of misaligned > > > address 0x5572a8d5f161 for type 'const __m128i *', which requires 16 byte > > > alignment > > > 0x5572a8d5f161: note: pointer points here > > > 2a 27 00 fc 75 47 2e 58 58 bf 5a d1 0f bb b4 48 98 72 83 ab e2 e8 b8 > > > 72 44 6d 71 24 02 1a 7a d2 > > > ^ > > > SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior > > > ../lib/crc-x86_64-pclmul.c:120:26 > > > > I puzzled because the source code line is: > > > > memcpy (final_buf, data, bytes_remaining); > > > > and memcpy is supposed to work on unaligned data. Is it that clang > > assumes that, since final_buf and data are both pointers to __m128i, > > clang can use instructions that require (instead of prefer) 16-byte > > alignment? > > Something like that, apparently. > > Due to the > "-fsanitize=address,undefined,signed-integer-overflow,shift,integer-divide-by-zero > -fno-sanitize-recover=undefined" > options, clang emits a call to __asan_memcpy instead of memcpy. > I don't know where ASAN gets the information about the type 'const __m128i *' > from, but I'm not familiar with the ASAN internals. > > Yes, the undefined behaviour really starts here, in line 35: > > const __m128i *data = buf; > > 'buf' was not aligned, 'const __m128i *' is 16-byte aligned.
Disassemble the code around that line. See which asm instruction is being used for the load. I suspect MOVDQA (aligned) is being used instead of MOVDQU (unaligned). Jeff
