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.

  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: link
Be 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).