https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556
Bug ID: 95556
Summary: Not replacing __builtin___memcpy_chk() as documented
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pg...@j-davis.com
Target Milestone: ---
Created attachment 48686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48686&action=edit
Example 2
GCC's Object Size Checking doc says:
"There are built-in functions added for many common
string operation functions, e.g., for memcpy
__builtin___memcpy_chk built-in is provided. This
built-in has an additional last argument, which is
the number of bytes remaining in the object the dest
argument points to or (size_t) -1 if the size is not
known. The built-in functions are optimized into the
normal string functions like memcpy if the last
argument is (size_t) -1 or if it is known at compile
time that the destination object will not be
overflowed..."
https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html
In the attached example1.c, __builtin___memcpy_chk() is optimized into the
normal memcpy(), as expected.
But in a slightly different example2.c, it is not, despite an object size of
-1.
When the checked version is left in place (like example2.c), it causes a
significant regression in my case.
This is important because Ubuntu 18.04 uses _FORTIFY_SOURCE, which ends up
using __builtin___memcpy_chk() for memcpy. If gcc is arbitrarily leaving it in
place when it should be (according to the docs) optimized away, that affects a
lot of code.
I'm seeing this on Ubuntu 18.04 with both:
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
gcc-9 (Ubuntu 9.2.1-19ubuntu1~18.04.york0) 9.2.1 20191109
It happens with or without -fno-builtin-memcpy (which is not a surprise, since
I am directly calling the builtin version anyway).
Compiled using:
gcc-9 -O2 -c -S -o example1.S example1.c
gcc-9 -O2 -c -S -o example2.S example2.c
example1.S:50:
call memcpy@PLT
example2.S:75:
rep movsq
