https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556
Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- It is unclear what you are complaining about. for i in gcc-7 gcc-8 gcc-9 gcc-10 gcc; do echo $i; for j in 1 2 3; do /usr/src/$i/obj/gcc/cc1 -quiet -O2 pr95556-$j.c; done; grep 'memcpy\|rep.movs' pr95556-*.s; done gcc-7 pr95556-1.s: rep movsq pr95556-2.s: call memcpy pr95556-3.s: call memcpy gcc-8 pr95556-1.s: rep movsq pr95556-2.s: call memcpy pr95556-3.s: call memcpy gcc-9 pr95556-1.s: rep movsq pr95556-2.s: call memcpy pr95556-3.s: call memcpy gcc-10 pr95556-1.s: rep movsq pr95556-2.s: rep movsq pr95556-3.s: call memcpy gcc pr95556-1.s: rep movsq pr95556-2.s: rep movsq pr95556-3.s: call memcpy There are no __memcpy_chk calls, which means GCC did in all cases what is documented, replace the __builtin___memcpy_chk calls with the corresponding __builtin_memcpy calls and handled that as usually (which isn't always a library call, there are many different options how a builtin memcpy can be expanded and one can find tune that through various command line options. It depends on what CPU the code is tuned for, whether it is considered hot or cold code, whether the size is constant and what constant or if it is variable and what alignment guarantees the destination and source has.