public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit 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: Fri, 18 Mar 2022 18:02:39 +0000	[thread overview]
Message-ID: <bug-99578-4-OlwyhdqcOF@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 #36 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:32ca611c42658948f1b8883994796f35e8b4e74d

commit r12-7713-g32ca611c42658948f1b8883994796f35e8b4e74d
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 18 18:58:06 2022 +0100

    Allow (void *) 0xdeadbeef accesses without warnings [PR99578]

    Starting with GCC11 we keep emitting false positive -Warray-bounds or
    -Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
    style accesses (or memory/string routines to such pointers).
    This is a standard programming style supported by all C/C++ compilers
    I've ever tried, used mostly in kernel or DSP programming, but sometimes
    also together with mmap MAP_FIXED when certain things, often I/O registers
    but could be anything else too are known to be present at fixed
    addresses.

    Such INTEGER_CST addresses can appear in code either because a user
    used it like that (in which case it is fine) or because somebody used
    pointer arithmetics (including &((struct whatever *)NULL)->field) on
    a NULL pointer.  The middle-end warning code wrongly assumes that the
    latter case is what is very likely, while the former is unlikely and
    users should change their code.

    The following patch adds a min-pagesize param defaulting to 4KB,
    and treats INTEGER_CST addresses smaller than that as assumed results
    of pointer arithmetics from NULL while addresses equal or larger than
    that as expected user constant addresses.  For GCC 13 we can
    represent results from pointer arithmetics on NULL using
    &MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs.

    2022-03-18  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/99578
            PR middle-end/100680
            PR tree-optimization/100834
            * params.opt (--param=min-pagesize=): New parameter.
            * pointer-query.cc
            (compute_objsize_r) <case ARRAY_REF>: Formatting fix.
            (compute_objsize_r) <case INTEGER_CST>: Use maximum object size
instead
            of zero for pointer constants equal or larger than min-pagesize.

            * gcc.dg/tree-ssa/pr99578-1.c: New test.
            * gcc.dg/pr99578-1.c: New test.
            * gcc.dg/pr99578-2.c: New test.
            * gcc.dg/pr99578-3.c: New test.
            * gcc.dg/pr100680.c: New test.
            * gcc.dg/pr100834.c: New test.

  parent reply	other threads:[~2022-03-18 18:02 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
2022-03-18 18:02 ` cvs-commit at gcc dot gnu.org [this message]
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-OlwyhdqcOF@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).