From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id EC15D3858D35; Sun, 25 Jun 2023 14:12:50 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EC15D3858D35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1687702370;
	bh=TRKRsC2FJNb1mlg1s5PsBAkHG8YDgmkbW44LDjDBRac=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=lWQ4/YHHXUnMcAUf/oRch00IQ+v9UXT6hYeZuTfV7foMCN038EebE4RN7jw/zOUIj
	 C96nVEEniDdgcqwgCGStNT4Vh6v0aDKUZG9DaSMdtfz70z4ptzr5laMvKcTLeqlIqD
	 fwv35Bk86AhluGBmuXXeNGVtF3As43K0ufvC4Q1I=
From: "lsof at mailbox dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/110402] Bogus -Waddress warning that pointer comparison is
 always true
Date: Sun, 25 Jun 2023 14:12:50 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 13.1.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: lsof at mailbox dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-110402-4-0zVUVw0ZhG@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-110402-4@http.gcc.gnu.org/bugzilla/>
References: <bug-110402-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

--- 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; };
>=20
> _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 n=
ot
> be NULL [-Waddress]
>     4 |     return &m->v[key];
>       |     ^~~~~~
> ```
>=20
> The reason why the others in your testcase is not being warned about is m=
ore
> about the shape of the ?: and/or the comma operator getting in the way of
> moving the implict `!=3D0` into the `?:`.

I understand why it warns about `&m->v[key] !=3D 0`; but when contained in a
larger expression like ```(key < 0 ? 0 : &m->v[key]) (!=3D 0)``` I don't th=
ink
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] !=3D 0` can definitely evaluate to false. So I don't know why G=
CC is
emitting the warning here in the first place. Even the backend disagrees wi=
th
the frontend, because if it were true that `&m->v[key] !=3D 0` always evalu=
ates
as true as the diagnostic says, the optimizer would elide the check, but it
does not.=