[Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented

[jakub at gcc dot gnu.org]

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.