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 9995C385B19A; Mon, 28 Nov 2022 19:47:09 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9995C385B19A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1669664829;
	bh=wOkuMKgKaedXhmdUj+QQbaMeJ9WUG+0vO8Ael31vQMs=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=osGQyEoIzg4YK20jiImef0u36MkQuRKI9/xDrrwy2e6aVXtPp2u1JUfN4mGYKBBB1
	 JS1EWVB3AZCX31fYSgtGtzJI2pd7v6cKC9qGvmjmUU551QathOCqrT5tGegx6XqUSW
	 mm54mKUd9sqHGBb1hTrHTM4JVAahenYRCygVtCo4=
From: "tlange at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug analyzer/107882] [13 Regression] ICE in get_last_bit_offset, at
 analyzer/store.h:255 since 13-2582-g0ea5e3f4542832b8
Date: Mon, 28 Nov 2022 19:47:09 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: analyzer
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tlange at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 13.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-107882-4-vXK0XkP7Q0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-107882-4@http.gcc.gnu.org/bugzilla/>
References: <bug-107882-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=3D107882

--- Comment #2 from Tim Lange <tlange at gcc dot gnu.org> ---
Created attachment 53979
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D53979&action=3Dedit
patch for pr107882

I think the assertion here uncovered a bug. Currently, if the OTHER paramet=
er
of bit_range::contains_p is empty (i.e. of size zero), contains_p calls
get_last_bit_offset, which result is only defined for non-empty ranges. Bef=
ore
r13-2582-g0ea5e3f4542832b8, the contains_p check was inconsistent, e.g. for
(offset 1, size 1) and (offset 1, size 0), but true for (offset 0, size 2) =
and
(offset 1, size 0).

Not sure what the "right" fix is, as empty ranges sorta feel unnatural.
Treating [i, 0] as a subset of (k, n) if k <=3D i <=3D k+n seems somewhat
reasonable.=