public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "msebor at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/103483] context-sensitive ranges change triggers stringop-overread
Date: Sat, 11 Dec 2021 00:56:56 +0000	[thread overview]
Message-ID: <bug-103483-4-1ILJjBXZ3h@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-103483-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #13 from Martin Sebor <msebor at gcc dot gnu.org> ---
The warning for the test case in comment #12 isn't directly related to ranges:
it's issued simply because the invalid statement is in the IL and not
eliminated by DCE (the secret functions don't let it).  Similar warnings have
been issued in equivalent situations for constants propagated through inlining.
 Here's one for -Wnonnull (issued since GCC 7):

char *sink;

__attribute__ ((noinline, noipa)) int
null_safe_strlen (const char *p) { return p ?__builtin_strlen (p) : 0; }

static inline void copy (const char *p)
{
  int N = null_safe_strlen (p);
  if (N) /* disabling this branch prevents the warning */
    __builtin_memcpy (sink, p, N);
  else
    *sink = 0;
}

void f()
{
  copy (0); // bogus warning
}

In function ‘copy’,
    inlined from ‘f’ at z.c:17:3:
z.c:10:5: warning: argument 2 null where non-null expected [-Wnonnull]
   10 |     __builtin_memcpy (sink, p, N);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
z.c:10:5: note: in a call to built-in function ‘__builtin_memcpy’

All GCC warnings trigger on invalid statements in the IL, regardless of whether
the statements are in reality reachable.  This includes all warnings that
consider data flow like -Wnonnull, -Warray-bounds, and -Wformat-overflow among
many others.  Ranges just let them find more invalid statements than constants
alone would.  This is also the most basic reason why the -Wstringop- warnings
are issued for the test case in comment #0 or in or PR 103332.

Two changes are behind the spate of recent bug reports about these warnings for
std::string: 1) in GCC 11 we enabled a subset of warnings for code inlined from
system headers, and 2) in GCC 12 thanks to Ranger the range info has become
more accurate and tighter (larger lower bounds and smaller upper bounds).

Before Jonathan suppressed the warnings in r12-5874 in libstdc++, Andrew
MacLeod suggested temporarily (for GCC 12) disabling the context-sensitive
Ranger info and going back to global ranges, until we have a better way of
dealing with the increased accuracy.  That would reduce the number of false
positives but it would also correspondingly increase false negatives, and so
defeat one of the main reasons for Ranger: better quality warnings.  It might
still be a compromise to consider if the problem turns out to be sufficiently
severe and if we can think of a way of to handle the ranges better in the
future.  But with the libstdc++ suppression I'm not convinced the problem is
severe enough anymore.  And I also can't think of a solution that would let us
re-enable Ranger for warnings in the future.  Nothing I've tried so far has
showed much promise, and neither seems anything anyone has suggested.

Independently, I have been thinking about adding -Wmaybe- forms of some of
these warnings analogous to -Wmaybe-uninitialized (or corresponding levels), to
diagnose conditional problems as in:

  char a[4], b[8];

  void f (int i)
  {
    __builtin_memset (i ? a : b, 0, 7);   // okay for b, overflow for a: thus
"may overflow a"
  }

but I have not been considering disabling the existing warnings (or removing it
from -Wall) and issuing them only under the new option or some new level.  That
would in my mind be a drastic step back.

  parent reply	other threads:[~2021-12-11  0:56 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30  4:27 [Bug c++/103483] New: constexpr basic_string " john at mcfarlane dot name
2021-11-30  4:39 ` [Bug c++/103483] context-sensitive ranges change " pinskia at gcc dot gnu.org
2021-11-30 12:11 ` redi at gcc dot gnu.org
2021-11-30 17:56 ` [Bug middle-end/103483] " msebor at gcc dot gnu.org
2021-11-30 18:13 ` msebor at gcc dot gnu.org
2021-11-30 22:33 ` john at mcfarlane dot name
2021-12-01 16:38 ` aldyh at gcc dot gnu.org
2021-12-01 16:53 ` redi at gcc dot gnu.org
2021-12-01 23:38 ` pinskia at gcc dot gnu.org
2021-12-01 23:44 ` pinskia at gcc dot gnu.org
2021-12-02 22:14 ` msebor at gcc dot gnu.org
2021-12-09 23:24 ` cvs-commit at gcc dot gnu.org
2021-12-10 22:10 ` jason at gcc dot gnu.org
2021-12-11  0:56 ` msebor at gcc dot gnu.org [this message]
2021-12-11 22:43 ` jason at gcc dot gnu.org
2022-01-17 22:44 ` [Bug middle-end/103483] [12 regression] " jason at gcc dot gnu.org
2022-01-17 23:10 ` amacleod at redhat dot com
2022-01-18  0:47 ` msebor at gcc dot gnu.org
2022-01-28  2:02 ` pinskia at gcc dot gnu.org
2022-01-28  5:03 ` jason at gcc dot gnu.org
2022-01-28  6:38 ` law at gcc dot gnu.org
2022-01-28  7:48 ` redi at gcc dot gnu.org
2022-01-28 15:23 ` law at gcc dot gnu.org
2022-03-09 14:11 ` rguenth at gcc dot gnu.org
2022-03-14 23:58 ` msebor at gcc dot gnu.org
2022-05-06  8:32 ` [Bug middle-end/103483] [12/13 " jakub at gcc dot gnu.org
2022-10-19  9:43 ` rguenth at gcc dot gnu.org
2023-05-08 12:23 ` [Bug middle-end/103483] [12/13/14 " rguenth 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-103483-4-1ILJjBXZ3h@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).