[Bug c/114622] New: memcmp -Wstringop-overread false positive

[Bug c/114622] New: memcmp -Wstringop-overread false positive

[arnaud.lb at gmail dot com]

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

            Bug ID: 114622
           Summary: memcmp -Wstringop-overread false positive
           Product: gcc
           Version: 13.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: arnaud.lb at gmail dot com
  Target Milestone: ---

The following code:

```
inline __attribute__((always_inline))
int g(const char *haystack, const char *needle, long unsigned int needle_len)
{
        if (needle_len == 1 || needle_len == 0) {
                return 0;
        }
        return __builtin_memcmp(needle, haystack, needle_len-2);
}

int f(const char *c) {
        long unsigned int len = 1;
        return g(c, "=", len);
}
```

Results in the following warning:

```
In function 'int g(const char*, const char*, long unsigned int)',
    inlined from 'int f(const char*)' at <source>:13:10:
<source>:8:32: warning: 'int __builtin_memcmp(const void*, const void*, long
unsigned int)' specified bound 18446744073709551615 exceeds maximum object size
9223372036854775807 [-Wstringop-overread]
    8 |         return __builtin_memcmp(needle, haystack, needle_len-2);
      |                ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
```

From my understanding, the compiler knows needle_len to be in range [1,1] when
inlining g() in f(), but it also believes that line 8 (the memcmp call) is
feasible, so needle_len-2 is (uint64_t)1-2, which is 18446744073709551615.

Local gcc version 13.2.1 20240316 (Red Hat 13.2.1-7) (GCC) 

Reproducible since 12.x on godbolt

[Bug tree-optimization/114622] memcmp -Wstringop-overread false positive

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2024-04-08
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  I guess the easiest thing is to not run the late waccess pass at
-O0
or at -O0 do simulated VN as we do for uninit analysis to prune unreachable
paths.