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 c/108986] [11/12 Regression] Incorrect warning for [static] array parameter
Date: Sun, 19 Mar 2023 05:30:24 +0000	[thread overview]
Message-ID: <bug-108986-4-iW1qy1oxZ7@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108986-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:d0e59b5e849258ab00c82ccab37c5e8246a41c6a

commit r12-9283-gd0e59b5e849258ab00c82ccab37c5e8246a41c6a
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Mar 3 16:11:11 2023 +0100

    waccess: Fix two -Wnonnull warning issues [PR108986]

    The following patch fixes 2 issues with the -Wnonnull warning.

    One, fixed by the second hunk, is that the warning wording is bogus
    since r11-3305, instead of printing
    warning: argument 1 to âint[static 7]â is null where non-null expected
[-Wnonnull]
    it prints
    warning: argument 1 to âint[static 28]â is null where non-null expected
[-Wnonnull]
    access_size is measured in bytes, so obviously will be correct as array
    number of elements only if it is 1 byte element array.
    In the function, access_nelts is either constant (if sizidx == -1) or
    when the array size is determined by some other parameter, I believe a
value
    passed to that argument.
    Later on we query the range of it:
          if (get_size_range (m_ptr_qry.rvals, access_nelts, stmt, sizrng, 1))
    which I bet must just return accesS_nelts in sizrng[0] and [1] if it is
    constant.  access_size is later computed as:
          tree access_size = NULL_TREE;
          if (tree_int_cst_sgn (sizrng[0]) >= 0)
            {
              if (COMPLETE_TYPE_P (argtype))
                {
    ...
                        wide_int minsize = wi::to_wide (sizrng[0], prec);
                        minsize *= wi::to_wide (argsize, prec);
                        access_size = wide_int_to_tree (sizetype, minsize);
                      }
                }
              else
                access_size = access_nelts;
            }
    and immediately after this the code does:
          if (integer_zerop (ptr))
            {
              if (sizidx >= 0 && tree_int_cst_sgn (sizrng[0]) > 0)
                {
    some other warning wording
                }
              else if (access_size && access.second.static_p)
                {
    this spot
                }
            }
    So, because argtype is complete, access_size has been multiplied by
    argsize, but in case of this exact warning ("this spot" above)
    I believe access_nelts must be really constant, otherwise
    "some other warning wording" would handle it.  So, I think access_nelts
    is exactly what we want to print there.

    The other problem is that since the introduction of -Wdangling-pointer
    in r12-6606, the pass has early and late instances and while lots of
    stuff in the pass is guarded on being done in the late pass only,
    this particular function is not, furthermore it is emitting two different
    warnings in a loop and already messes up with stuff like clearing
    warning suppression for one of the warning (ugh!).  The end effect is
    that we warn twice about the same problem, once in the early and once in
    the late pass.  Now, e.g. with -O2 -Wall we warn just once, during the
    early pass, as it is then optimized away, so I think just making this
    late warning only wouldn't be best.  This patch instead returns early
    if either of the warnings is suppressed on the call stmt already.
    I think if one of the passes warned on it already (even if say on some
other
    argument), then warning again (even on some other argument) is unnecessary,
    if both problems are visible in the same pass we'll still warn about both.

    2023-03-03  Jakub Jelinek  <jakub@redhat.com>

            PR c/108986
            * gimple-ssa-warn-access.cc
(pass_waccess::maybe_check_access_sizes):
            Return immediately if OPT_Wnonnull or OPT_Wstringop_overflow_ is
            suppressed on stmt.  For [static %E] warning, print access_nelts
            rather than access_size.  Fix up comment wording.

            * gcc.dg/Wnonnull-8.c: New test.

    (cherry picked from commit 1b0e3f8ca369f63d3e1a8e1c268d93530035503a)

  parent reply	other threads:[~2023-03-19  5:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-01 18:35 [Bug c/108986] New: " Keith.S.Thompson at gmail dot com
2023-03-01 18:41 ` [Bug c/108986] " Keith.S.Thompson at gmail dot com
2023-03-02 10:11 ` rguenth at gcc dot gnu.org
2023-03-02 15:42 ` [Bug c/108986] [11/12/13 Regression] " jakub at gcc dot gnu.org
2023-03-02 18:09 ` jakub at gcc dot gnu.org
2023-03-03 15:12 ` cvs-commit at gcc dot gnu.org
2023-03-03 15:19 ` [Bug c/108986] [11/12 " jakub at gcc dot gnu.org
2023-03-19  5:30 ` cvs-commit at gcc dot gnu.org [this message]
2023-03-20 10:28 ` [Bug c/108986] [11 " jakub at gcc dot gnu.org
2023-05-08 12:26 ` rguenth at gcc dot gnu.org
2023-08-04 14:06 ` muecker at gwdg dot de

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-108986-4-iW1qy1oxZ7@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).