https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110402
--- Comment #3 from lsof at mailbox dot org ---
(In reply to Andrew Pinski from comment #2)
> We warn about:
> ```
> struct m { float *v; int t; };
>
> _Bool chk1(struct m *m, int key) {
> return &m->v[key];
> }
> ```
> ```
> <source>: In function 'chk1':
> <source>:4:5: warning: the comparison will always evaluate as 'true' for the
> pointer operand in 'm->v + (sizetype)((long unsigned int)key * 4)' must not
> be NULL [-Waddress]
> 4 | return &m->v[key];
> | ^~~~~~
> ```
>
> The reason why the others in your testcase is not being warned about is more
> about the shape of the ?: and/or the comma operator getting in the way of
> moving the implict `!=0` into the `?:`.
I understand why it warns about `&m->v[key] != 0`; but when contained in a
larger expression like ```(key < 0 ? 0 : &m->v[key]) (!= 0)``` I don't think
the warning is useful.
(In reply to Andreas Schwab from comment #1)
> The error message does not match anything from the test case.
Now that I think about it, you're right; if `m->v` is null and `key` is 0,
`&m->v[key] != 0` can definitely evaluate to false. So I don't know why GCC is
emitting the warning here in the first place. Even the backend disagrees with
the frontend, because if it were true that `&m->v[key] != 0` always evaluates
as true as the diagnostic says, the optimizer would elide the check, but it
does not.
