[Bug c/94444] New: __attribute__((access(...))) ignored for memcpy when compiling with -Os

[Bug c/94444] New: __attribute__((access(...))) ignored for memcpy when compiling with -Os

[felix-gcc at fefe dot de]

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

            Bug ID: 94444
           Summary: __attribute__((access(...))) ignored for memcpy when
                    compiling with -Os
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

I read about the access attribute and proceeded to add the annotations to the
string.h of my little libc. It works. But it stops working when I compile with
-Os.

I suspect it's because gcc is switching to __buildin_memcpy then?

[Bug c/94444] __attribute__((access(...))) ignored for memcpy when compiling with -Os

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That makes no sense, access attribute can help for functions which GCC doesn't
know in detail what they do, but e.g. memcpy is something GCC has better
understanding of compared to what access attribute can even describe, and uses
it in various optimization passes.

[Bug c/94444] __attribute__((access(...))) ignored for memcpy when compiling with -Os

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-04-01
                 CC|                            |msebor at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |WAITING

--- Comment #2 from Martin Sebor <msebor at gcc dot gnu.org> ---
Can you include a small test case that reproduce the problem (and the full
command line used to reproduce it)?  I can't think of a reason why the
attribute would be completely ineffective with -Os and a simple test case
confirms it does the right thing even with with -fno-builtin-memcpy (if the
built-in happens to be disabled while building libc).  GCC recognizes
__builtin_memcpy as special (built-ins aren't decorated with the attribute in
GCC 10) so it should have the same detection as functions explicitly declared
with the attribute.

$ cat z.c && gcc -Os -S -fno-builtin-memcpy z.c
__attribute__ ((access (write_only, 1, 3), access (read_only, 2, 3)))
void* memcpy (void*, const void*, __SIZE_TYPE__);

char a[3];

void f (const void *s)
{
  memcpy (a, s, 5);
}

void g (const void *s)
{
  __builtin_memcpy (a, s, 5);
}

z.c: In function ‘f’:
z.c:8:3: warning: ‘memcpy’ writing 5 bytes into a region of size 3 overflows
the destination [-Wstringop-overflow=]
    8 |   memcpy (a, s, 5);
      |   ^~~~~~~~~~~~~~~~
z.c:2:7: note: in a call to function ‘memcpy’ declared with attribute
‘write_only (1, 3)’
    2 | void* memcpy (void*, const void*, __SIZE_TYPE__);
      |       ^~~~~~
z.c: In function ‘g’:
z.c:13:3: warning: ‘__builtin_memcpy’ writing 5 bytes into a region of size 3
overflows the destination [-Wstringop-overflow=]
   13 |   __builtin_memcpy (a, s, 5);
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~

[Bug c/94444] __attribute__((access(...))) ignored for memcpy when compiling with -Os

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note the access attribute is only for diagnostics, not for optimization.

[Bug c/94444] __attribute__((access(...))) ignored for memcpy when compiling with -Os

[felix-gcc at fefe dot de]

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

--- Comment #4 from felix-gcc at fefe dot de ---
Sure, here's a test case:

#include <stddef.h>

__attribute__((access(read_only,2,3), access(write_only,1,3)))
extern void* memcpy(void* dest, const void* src, size_t len);

int main() {
  char buf[10];
  memcpy(buf,"fnordfnord",11);  // should reject or at least warn
}


$ gcc -c t.c
t.c: In function ‘main’:
t.c:8:3: warning: ‘memcpy’ writing 11 bytes into a region of size 10 overflows
the destination [-Wstringop-overflow=]
    8 |   memcpy(buf,"fnordfnord",11); // should reject or at least warn
      |   ^~~~~~~~~~~~~~~~~~~~~~~~~~~
t.c:4:14: note: in a call to function ‘memcpy’ declared with attribute
‘write_only (1, 3)’
    4 | extern void* memcpy(void* dest, const void* src, size_t len);
      |              ^~~~~~
$ gcc -c t.c -Os
$ gcc -v
[...]
gcc version 10.0.1 20200401 (experimental) (GCC)

[Bug c/94444] __attribute__((access(...))) ignored for memcpy when compiling with -Os

[msebor at gcc dot gnu.org]

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

Martin Sebor <msebor at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |WONTFIX
           Keywords|                            |diagnostic

--- Comment #5 from Martin Sebor <msebor at gcc dot gnu.org> ---
Attribute access has an effect only on calls present in the IL after all
optimizations have run.  In the test case, because the local variable isn't
used after the copy, the call is removed and there is no warning.  (The warning
comes back if the buffer is used or made extern or static.)  This is by design,
and expected not just of the attribute but of most late warnings (including,
for example, -Warray-bounds).  Doing otherwise and processing the attribute
much earlier would lead to warnings for unreachable code that most users view
as false positives.  We have no plans to change it.