From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8DA4B395201E; Thu, 17 Mar 2022 12:52:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8DA4B395201E From: "jakub 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: Thu, 17 Mar 2022 12:52:40 +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: jakub 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: attachments.created 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: Thu, 17 Mar 2022 12:52:41 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D99578 --- Comment #35 from Jakub Jelinek --- Created attachment 52643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D52643&action=3Dedit gcc12-pr99578-wip.patch What we could do is differentiate between the invalid constant addresses from pointer arithmetics on NULL or propagation of NULL into &ptr->field and valid (type *)constant used heavily in real-world code and accepted by = all major compilers by representing the former internally as &MEM_REF[(void *)0B + offset] while the user (type *)constant as INTEGER_CS= Ts. That in full seems like a stage1 task because we'd need to ensure we don't regress much by doing that. Some things would be unavoidable (like avoiding SCCVN of those pointer INTEGER_CSTs vs. the &MEM_REF[(void *)0B + offset] form), e.g. equality comparison of &MEM_REF[(void *)0B + CST] vs. (void *)CST shou= ld be optimized etc., and we would need to force that form even on say (int *)0 += 24 etc. in the FEs. But we badly need to fix this for GCC 12 and backport to GCC 11. So this WIP patch treats addresses in the first page (a param defaulting to 4KB) temporarily as emitting the warnings as before in GCC 11/12, and only creat= es the &MEM_REF[(void *)0B + offset] form for larger offsets which will make t= hem very rare. Some further tweaks will be needed on the gimple-array-bounds* etc. side so that we treat those &MEM_REF[(void *)0B + offset] as equivalent to the GCC 11 up= to current trunk handling of (void *)offset, so that say on: struct S { int a, b[4]; }; struct T { int a, b[8192], c[4]; }; void foo (struct S *p) { if (p) return; __builtin_memset (p->b, 0, sizeof p->b); } void bar (struct T *p) { if (p) return; __builtin_memset (p->c, 0, sizeof p->c); } one gets the same warnings rather than different. On IRC Richi suggested just the params.opt and pointer-query.cc (compute_objsize_r) hunks which would only warn above in foo and not in bar= .=