[Bug c/114609] New: -Waddress false positive

2024-04-05 Thread arnaud.lb at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114609

Bug ID: 114609
   Summary: -Waddress 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:

```
struct {
int member;
} state;

int effect;

void f(void) {
effect = ((&state)->member == 1 ? &state : 0) ? 2 : 3;
}
```

When compiled with:

```
gcc -c test.c -Waddress
```

Results in the following warning:

```
: In function 'f':
:8:51: warning: the address of 'state' will always evaluate as 'true'
[-Waddress]
8 | effect = ((&state)->member == 1 ? &state : 0) ? 2 : 3;
  |   ^
Compiler returned: 0
```

I believe this is a false positive, and no warning should be emitted.

GCC version: 13.2.1 20240316 (Red Hat 13.2.1-7)

[Bug c/114609] -Waddress false positive

2024-04-05 Thread arnaud.lb at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114609

--- Comment #2 from arnaud.lb at gmail dot com ---
I can not think of any location where this warning would make sense for this
code. The warning behaves as if we did this:

```
(&state)->member == 1 ? (_Bool)&state : (_Bool)0) ? 2 : 3;
```

In this case it would make sense as (_Bool)&state will indeed always be true.

The original code looks more like this:

```
struct {
_Bool valid;
} state;

int effect;

#define getState() ((&state)->valid == 1 ? &state : 0)

void f(void) {
effect = getState() ? 2 : 3;
}
```

The warning is unfortunate because the code is not explicitly testing the
address of `state`.

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

2024-04-06 Thread arnaud.lb at gmail dot com via Gcc-bugs
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 :13:10:
: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