From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id 877BA3857C5F; Wed,  9 Mar 2022 14:11:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 877BA3857C5F
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/103483] [12 regression] context-sensitive ranges
 change triggers stringop-overread
Date: Wed, 09 Mar 2022 14:11:00 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 12.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-103483-4-JDnIlD5EkL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-103483-4@http.gcc.gnu.org/bugzilla/>
References: <bug-103483-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Mar 2022 14:11:01 -0000

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

--- Comment #22 from Richard Biener <rguenth at gcc dot gnu.org> ---
There isn't going to be a good solution that makes all folks happy - we'd
either have false negatives or false positives.  It is true that we're
accumulating more and more cases where the user gets the impression we want=
 to
warn about

int a[16];
void foo (size_t len)
{
  memset (a, 0, len);
}

like

warning: memset called with unbound 'len' argument to buffer of size 16

for example we do not diagnose

int a[2];
void foo (unsigned len)
{
  if (len =3D=3D 1 || len =3D=3D 20)
    __builtin_memset (a, 0, len);
}

even though with len =3D=3D 20 this is out of bounds.  Instead we only
diagnose if both possible accesses are out of bounds but we fail
to see that in the 'else' case we do not call memset at all.  What's
the real difference to the len =3D=3D 1 case that makes us to not
emit the diagnostics here?

What we traditionally consider as "always" and "maybe" is also blurry
with more and more IPA optimization (functions are always only "maybe"
executed).

What static analyzers and fuzzers do is isolate every possible path,
sensible or not, and diagnose those.  We're getting closer to that
(but every non-sensical isolated path also consumes object space).=