public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-99578-4-fvWXwfonqf@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99578-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Created attachment 52643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52643&action=edit 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_CSTs. 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 should 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 creates the &MEM_REF[(void *)0B + offset] form for larger offsets which will make them 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.
next prev parent reply other threads:[~2022-03-17 12:52 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-13 14:23 [Bug c/99578] New: " arnd at linaro dot org 2021-03-13 20:40 ` [Bug c/99578] " msebor at gcc dot gnu.org 2021-03-13 21:40 ` arnd at linaro dot org 2021-03-13 22:38 ` arnd at linaro dot org 2021-03-14 0:57 ` [Bug middle-end/99578] " msebor at gcc dot gnu.org 2021-03-14 11:54 ` arnd at linaro dot org 2021-03-14 21:25 ` arnd at linaro dot org 2021-03-15 8:38 ` rguenth at gcc dot gnu.org 2021-03-15 19:57 ` msebor at gcc dot gnu.org 2021-03-15 20:24 ` msebor at gcc dot gnu.org 2021-04-21 19:34 ` pinskia at gcc dot gnu.org 2021-04-28 16:11 ` msebor at gcc dot gnu.org 2021-05-01 15:08 ` andi-gcc at firstfloor dot org 2021-05-19 15:07 ` msebor at gcc dot gnu.org 2021-05-19 18:01 ` andrew.cooper3 at citrix dot com 2021-05-19 19:19 ` andrew.cooper3 at citrix dot com 2021-05-19 20:48 ` msebor at gcc dot gnu.org 2021-05-30 23:40 ` msebor at gcc dot gnu.org 2021-08-24 16:03 ` pinskia at gcc dot gnu.org 2021-09-14 18:46 ` [Bug middle-end/99578] [11/12 Regression] " pinskia at gcc dot gnu.org 2021-12-19 11:36 ` pinskia at gcc dot gnu.org 2021-12-21 13:53 ` pmenzel+gcc at molgen dot mpg.de 2022-01-14 15:57 ` pmenzel+gcc at molgen dot mpg.de 2022-01-21 13:18 ` rguenth at gcc dot gnu.org 2022-02-23 10:36 ` pinskia at gcc dot gnu.org 2022-02-23 12:53 ` jakub at gcc dot gnu.org 2022-02-23 16:50 ` msebor at gcc dot gnu.org 2022-02-23 16:57 ` jakub at gcc dot gnu.org 2022-02-23 17:55 ` msebor at gcc dot gnu.org 2022-03-07 19:30 ` pinskia at gcc dot gnu.org 2022-03-07 20:53 ` goswin-v-b at web dot de 2022-03-16 19:49 ` kees at outflux dot net 2022-03-16 21:15 ` msebor at gcc dot gnu.org 2022-03-16 23:10 ` jwerner at chromium dot org 2022-03-17 10:49 ` redi at gcc dot gnu.org 2022-03-17 10:53 ` redi at gcc dot gnu.org 2022-03-17 12:52 ` jakub at gcc dot gnu.org [this message] 2022-03-18 18:02 ` cvs-commit at gcc dot gnu.org 2022-03-18 18:05 ` [Bug middle-end/99578] [11 " jakub at gcc dot gnu.org 2022-03-19 11:02 ` goswin-v-b at web dot de 2022-03-29 5:54 ` cvs-commit at gcc dot gnu.org 2022-03-30 8:04 ` marxin at gcc dot gnu.org 2022-03-30 8:16 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-99578-4-fvWXwfonqf@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).