From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A7AD73857C4A; Wed, 23 Feb 2022 16:50:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A7AD73857C4A From: "msebor at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal Date: Wed, 23 Feb 2022 16:50:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 11.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: normal X-Bugzilla-Who: msebor at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.3 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 16:50:08 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99578 --- Comment #25 from Martin Sebor --- (In reply to Jakub Jelinek from comment #24) > (In reply to Martin Sebor from comment #1) > > The warning is by design. >=20 > That just means the design is bad. Especially in the embedded world, usi= ng > memory mapped IO at fixed addresses is very common and we really shouldn't > force > people to pessimize their code by adding volatile on the pointers etc. No, the design is perfectly fine: it enforces the constraint in the standard that require pointers to point to live objects when they're used.=20 Implementations can impose less restrictive constraints and implement behav= ior the standard leaves undefined by providing extensions. But to distinguish = the two kinds of behavior they need to document the extensions. Failing to do = that only leads to confusion and bugs (this code worked just fine in version X of GCC but version Y broke it!) Following this simple approach not only improves the quality of the implementation but also helps guide decisions about what's helpful to diagn= ose and what should be silently accepted. > > Its purpose is to detect invalid accesses at > > non-zero offsets to null pointers, like in the memset call below: > >=20 > > struct S { int a, b[4]; }; > >=20 > > void f (struct S *p) > > { > > if (p) return; > > memset (p->b, 0, 4 * sizeof p->b); > > } > >=20 > > For now, I recommend suppressing the warning either by #pragma GCC > > diagnostic or by making the pointer volatile. In the future, providing= an > > attribute to annotate constant addresses with (or extending the io() > > attribute supported by some targets to all targets) might be another wa= y to > > avoid it. >=20 > Then perhaps just add some flag on the INTEGER_CSTs created from folding > &ptr->member into constant (seems currently that happens during {,e}vrp a= nd > dom) and only in the spots you warn if the INTEGER_CST has that flag set? In my opinion, code that deliberately uses invalid pointers (e.g., hardwired addresses) should be explicitly annotated, e.g., by some attribute. This approach has at least two advantages: 1) it makes the intent clear to the reader, and 2) by declaring the object it lets GCC enforce type safety as w= ell as check for out-of-bounds access to it. GCC already provides two such attributes: the AVR address and io attributes. Rather than relying on heuristics I would suggest to make the address attribute (or one like it) available on all targets and use it for this purpose. (I started working o= n it last November but didn't finish it.)=