https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 31 Mar 2021, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99828 > > --- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> --- > All right, I vanished the test-case: > > $ cat 1.i > inline __attribute__((__always_inline__)) __attribute__((gnu_inline)) void * > memcpy(); > void *apply_relocate_add_write = memcpy; > > $ touch 2.s > $ cat 3.i > enum { false, true } * __memcpy(); ?? obviously bad reduction. > _Bool kasan_check_range(); > void *memcpy(void *dest, void *src, long len) { > if (kasan_check_range(len, false, 0) || kasan_check_range(len, true, 0)) > return __memcpy(dest, src, len); > } > > long LZ4_decompress_generic_dst_restSize; > char LZ4_decompress_generic_dst_lowPrefix; > void LZ4_decompress_generic_dst() { > __builtin_memcpy(LZ4_decompress_generic_dst, > &LZ4_decompress_generic_dst_lowPrefix, > LZ4_decompress_generic_dst_restSize); I wonder if this use of __builtin_memcpy intends to not use the kernels always-inline memcpy but GCCs own inline expansion? This obviously doesn't work, not with LTO at least. It looks like with kasan enabled (and memcpy "wrapped") the memcpy declaration should _not_ have the always-inline (since the implementation is no longer always-inline). That would be a fix on the kernel side, but I'd also diagnose any such always-inline "mismatch" we get to at WPA.
