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 606A23959C9C; Wed, 16 Nov 2022 14:54:14 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 606A23959C9C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1668610454;
	bh=IGIvKBjCkzLCJ+FWjyBwpc6I+jHoOPrMr4pBWrPbsyo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=UUsoqRmjZvm+9jSi/tpd9MIZ2NOwHiGUMwHfoU/3bf7boj4hj7455FhrLmUE9g0PO
	 agrckgjJECk6XtRVMvqTqGh8+MlyRdOZdSDlrIJp1VpNEcys0QxrA4duF3+x7QihpE
	 ccn+tAdOM/frRfX0zhigDBSEJluNTOeclBRY1XLU=
From: "carlosgalvezp at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107699] [12/13 Regression] False positive
 -Warray-bounds, non-existent offset reported by GCC
Date: Wed, 16 Nov 2022 14:54:10 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: carlosgalvezp at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.3
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107699-4-sXEmHtwGxx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107699-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107699-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
List-Id: <gcc-bugs.sourceware.org>

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

--- Comment #2 from Carlos Galvez <carlosgalvezp at gmail dot com> ---
Looking deeply at the stacktrace, I see that std::sort ends up in this kind=
 of
code:

      if (__last - __first > int(_S_threshold))
        {
          std::__insertion_sort(__first, __first + int(_S_threshold), __com=
p);

Since the __last iterator cannot be known at compile time, this "if" branch
must be generated by the compiler. But then std::sort has hardcoded this
_S_threshold =3D 16, and computes a pointer __first + 16, which is known to=
 be
OOB.

The question is: should the compiler *really* warn in this type of code, in
-Wall, which is the bare-minimum warning level for all projects? While I can
see the usefulness, the sheer amount of false positives (see meta bug-track=
er)
does not qualify this warning from being part of -Wall IMHO. This diagnostic
fits better as "-Wmaybe-array-bounds".=20

The worst part is that people need to disable this warning globally, theref=
ore
losing warning coverage on *true* OOB accesses happening in user code.=