From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AE415385C311; Wed, 14 Sep 2022 07:37:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AE415385C311 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663141052; bh=nqTYMcUFSLc9IPyOZk6Jqd1ZqiZxIfyeCi5GzkbRnuc=; h=From:To:Subject:Date:In-Reply-To:References:From; b=RtO254B6ZAYGqHOmQpsMXGmfHQcNwoc/KvVicF+d5YxjbhaJxoBuNYsQQvZkrUzDN KcFq7k9rlu8bOMbUr8gL4s1FCAyWJKPCjpMPvLmglhc7zSW9x7T8nfOcEqFSMdX7xu ivFh1xm6b+nPQYjHTaI+zZvGnVtoOBDKsjKYAKz4= From: "npfhrotynz-ptnqh.myvf at noclue dot notk.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/106920] -Warray-bound false positive regression with -O2 or -Os and constant address Date: Wed, 14 Sep 2022 07:37:32 +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: 12.2.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: npfhrotynz-ptnqh.myvf at noclue dot notk.org X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: DUPLICATE 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106920 --- Comment #5 from Dominique Martinet --- hmm this is a pretty complex topic. My problem like pointed out in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99578 is more with all the l= egacy code that I have to deal with, that isn't maintained by anyone, and well the sorry state of embedded systems upstreams in general... So I'm really just sitting there trying to get old code to keep working with my newer gcc vers= ion. (I actually wonder why that didn't fail with gcc11, I've been using that fo= r a while...) The solution in that other bug ^ to just not issue warnings for constant addresses is good in general and I was just unlucky that such an address happened below 4k for this code. I don't understand why the ast tree cannot make the difference between a constant address and a constant null pointer macroed to hell, but since that only happens with optimizations enabled I guess some info is lost at that p= oint and there was nothing to do or it would have been done. Anyway, I consider that closed, there's been enough ink spilled in the other thread and thank you all for the quick replies!=