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 94E00384CBBD; Fri, 15 Dec 2023 13:57:17 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 94E00384CBBD
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1702648637;
	bh=SpXmDfwkzSBtAdPJsnqlQWif3oXZXOHFiEUVWxDhkj8=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=GVGq9GWmNxH0Ec1IlgX2Uox63SyQOSixKbsm1Z6j7s4KZaAFT2JWTKBwSjSWEnLUs
	 Staygik2tTHtKGLe2wbuR4fPd8nvNryoWEHO0jGAJNz6WLVPuem8k1LJSuogS4aU9u
	 jChwgv7oQ7NMAWlJnhZCzMOPxoS8MAfbsn4kvfQc=
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/107699] [12/13/14 Regression] False positive
 -Warray-bounds, non-existent offset reported by GCC
Date: Fri, 15 Dec 2023 13:57:16 +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: rguenth at gcc dot gnu.org
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.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-107699-4-cRjZryMqmT@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 #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Carlos Galvez from comment #11)
> Consider this more realistic example:
>=20
> https://godbolt.org/z/jbbqbe8d9
>=20
> The compiler has all the information available to ensure that
> getCount().get() is smaller than 3, as enforced by the class invariant wh=
ich
> is visible to the compiler. Class invariants help us not having to check
> things all the time. For example gsl::not_null allows us to not have to
> check for nullptr on every use.

This doesn't really change anything as the compiler doesn't see the
CTOR invoked or that 'x' isn't changed before being returned.

I think we want to somehow prevent the diagnostic on the library side.

This particular case is

  /// This is a helper function for the sort routine.
  template<typename _RandomAccessIterator, typename _Compare>
    _GLIBCXX20_CONSTEXPR
    void=20=20=20=20=20=20
    __final_insertion_sort(_RandomAccessIterator __first,
                           _RandomAccessIterator __last, _Compare __comp)
    {=20=20=20=20=20
      if (__last - __first > int(_S_threshold))
        {=20
          std::__insertion_sort(__first, __first + int(_S_threshold), __com=
p);
          std::__unguarded_insertion_sort(__first + int(_S_threshold), __la=
st,
                                          __comp);
        }=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
      else
        std::__insertion_sort(__first, __last, __comp);

where we diagnose __first + int(_S_threshold) when that's visibly out-of-bo=
unds
but __last - __first isn't constant.  I'm not exactly sure how
(I'm also not sure why we do the above thing, handling the first elements
separate from the rest...)?=