public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented
@ 2020-06-06  1:22 pgsql@j-davis.com
  2020-06-06  1:23 ` [Bug c/95556] " pgsql@j-davis.com
                   ` (9 more replies)
  0 siblings, 10 replies; 11+ messages in thread
From: pgsql@j-davis.com @ 2020-06-06  1:22 UTC (permalink / raw)
  To: gcc-bugs

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: pgsql@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

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
@ 2020-06-06  1:23 ` pgsql@j-davis.com
  2020-06-06  1:50 ` [Bug middle-end/95556] " pgsql@j-davis.com
                   ` (8 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pgsql@j-davis.com @ 2020-06-06  1:23 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

--- Comment #1 from Jeff Davis <pgsql@j-davis.com> ---
Created attachment 48687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48687&action=edit
Example 1

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
  2020-06-06  1:23 ` [Bug c/95556] " pgsql@j-davis.com
@ 2020-06-06  1:50 ` pgsql@j-davis.com
  2020-06-06  1:53 ` [Bug c/95556] " pgsql@j-davis.com
                   ` (7 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pgsql@j-davis.com @ 2020-06-06  1:50 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

--- Comment #2 from Jeff Davis <pgsql@j-davis.com> ---
Created attachment 48688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48688&action=edit
Example 3

Another example that works (i.e. builtin is properly replaced by memcpy as
described in the document).

The only difference between this working example and the failing example2.c is
that I replaced the sizeof() with a constant.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug c/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
  2020-06-06  1:23 ` [Bug c/95556] " pgsql@j-davis.com
  2020-06-06  1:50 ` [Bug middle-end/95556] " pgsql@j-davis.com
@ 2020-06-06  1:53 ` pgsql@j-davis.com
  2020-06-06  9:42 ` [Bug middle-end/95556] " jakub at gcc dot gnu.org
                   ` (6 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pgsql@j-davis.com @ 2020-06-06  1:53 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

--- Comment #3 from Jeff Davis <pgsql@j-davis.com> ---
Original larger case was discovered in PostgreSQL:

https://www.postgresql.org/message-id/99b2eab335c1592c925d8143979c8e9e81e1575f.camel@j-davis.com

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
                   ` (2 preceding siblings ...)
  2020-06-06  1:53 ` [Bug c/95556] " pgsql@j-davis.com
@ 2020-06-06  9:42 ` jakub at gcc dot gnu.org
  2020-06-06  9:55 ` jakub at gcc dot gnu.org
                   ` (5 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-06-06  9:42 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
                   ` (3 preceding siblings ...)
  2020-06-06  9:42 ` [Bug middle-end/95556] " jakub at gcc dot gnu.org
@ 2020-06-06  9:55 ` jakub at gcc dot gnu.org
  2020-06-06  9:59 ` jakub at gcc dot gnu.org
                   ` (4 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-06-06  9:55 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
And note that
-      if (lt->pos >= (8192-sizeof(S)))
+      if (lt->pos >= (8192-16))
is not an insignificant change, the first one is unsigned comparison, the
second one signed.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
                   ` (4 preceding siblings ...)
  2020-06-06  9:55 ` jakub at gcc dot gnu.org
@ 2020-06-06  9:59 ` jakub at gcc dot gnu.org
  2020-06-06 17:09 ` pgsql@j-davis.com
                   ` (3 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-06-06  9:59 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
See -mno-align-stringops, -minline-all-stringops,
-minline-stringops-dynamically, -mstringop-strategy= , -mmemcpy-strategy=
options and their documentation in the GCC manual.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
                   ` (5 preceding siblings ...)
  2020-06-06  9:59 ` jakub at gcc dot gnu.org
@ 2020-06-06 17:09 ` pgsql@j-davis.com
  2020-06-06 17:18 ` jakub at gcc dot gnu.org
                   ` (2 subsequent siblings)
  9 siblings, 0 replies; 11+ messages in thread
From: pgsql@j-davis.com @ 2020-06-06 17:09 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

--- Comment #7 from Jeff Davis <pgsql@j-davis.com> ---
"...built-in functions are optimized into the normal string functions like
memcpy if the last argument is (size_t) -1..."

My reading of the document lead me to believe that a last argument of -1
*would* be a normal library call. And certainly should be with
-fno-builtin-memcpy, right?

If that's not what's happening, should the document be clarified?

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
                   ` (6 preceding siblings ...)
  2020-06-06 17:09 ` pgsql@j-davis.com
@ 2020-06-06 17:18 ` jakub at gcc dot gnu.org
  2020-06-07 15:31 ` pgsql@j-davis.com
  2020-06-07 15:37 ` jakub at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-06-06 17:18 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jeff Davis from comment #7)
> "...built-in functions are optimized into the normal string functions like
> memcpy if the last argument is (size_t) -1..."
> 
> My reading of the document lead me to believe that a last argument of -1
> *would* be a normal library call. And certainly should be with
> -fno-builtin-memcpy, right?

No.  Because -fno-builtin-memcpy only disables the special behavior if one uses
memcpy, when one uses __builtin_memcpy, it behaves always as builtin.  And you
are using __builtin___memcpy_chk which is also a builtin and thus not affected
by -fno-builtin*.
You can use -fno-builtin-__memcpy_chk but then you'll get __memcpy_chk calls if
you call it that way.
As I wrote, if you for whatever reason want to use the library call, e.g.
always, you can just use -mmemcpy-strategy=libcall:-1:1 or so, but then even
very small ones will not be done inline, which is not really beneficial.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
                   ` (7 preceding siblings ...)
  2020-06-06 17:18 ` jakub at gcc dot gnu.org
@ 2020-06-07 15:31 ` pgsql@j-davis.com
  2020-06-07 15:37 ` jakub at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: pgsql@j-davis.com @ 2020-06-07 15:31 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

--- Comment #9 from Jeff Davis <pgsql@j-davis.com> ---
I still feel like the documentation is misleading on this point.

Regardless, it doesn't seem like you think there is any bug here, so go ahead
and close.

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
  2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
                   ` (8 preceding siblings ...)
  2020-06-07 15:31 ` pgsql@j-davis.com
@ 2020-06-07 15:37 ` jakub at gcc dot gnu.org
  9 siblings, 0 replies; 11+ messages in thread
From: jakub at gcc dot gnu.org @ 2020-06-07 15:37 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
.

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-06-07 15:37 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-06  1:22 [Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented pgsql@j-davis.com
2020-06-06  1:23 ` [Bug c/95556] " pgsql@j-davis.com
2020-06-06  1:50 ` [Bug middle-end/95556] " pgsql@j-davis.com
2020-06-06  1:53 ` [Bug c/95556] " pgsql@j-davis.com
2020-06-06  9:42 ` [Bug middle-end/95556] " jakub at gcc dot gnu.org
2020-06-06  9:55 ` jakub at gcc dot gnu.org
2020-06-06  9:59 ` jakub at gcc dot gnu.org
2020-06-06 17:09 ` pgsql@j-davis.com
2020-06-06 17:18 ` jakub at gcc dot gnu.org
2020-06-07 15:31 ` pgsql@j-davis.com
2020-06-07 15:37 ` jakub at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).