From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id F34B938582B1; Mon, 4 Dec 2023 18:19:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F34B938582B1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1701713949; bh=DygDbOmlOS5ahn4oNmdykyFbfWiL1zjQAaIrDvFB/LQ=; h=From:To:Subject:Date:In-Reply-To:References:From; b=N8LJbv/PXYyDH+xaBqXaSdDKKORIdiWLxKQQ1+0I0cYKUsURWkpICc8RKctMORBjw 1zMb4PlEfSHEPhmZxCVec7q/iHIUvh3rBZYQ6e9qO9TvLV5+QRfL+dJs55z6XOhkdu 9QMFJqIYYrkAeKGtuAo5IJmQ14dxsrzkG7e81/is= From: "amacleod at redhat dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1 Date: Mon, 04 Dec 2023 18:19:08 +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: 14.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: amacleod at redhat dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112843 --- Comment #9 from Andrew Macleod --- Created attachment 56790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D56790&action=3Dedit auxially patch to avid the trap refining a range is fine... the only issue we are really running into here that is causing the trap is that the "update" on the original LHS DEF is a = new stmt which hasnt been added to the IL yet, so ranger is trapping when it as= ks for the basic block of the def stmt.. It had one before, it expects it to s= till have one when it looks at the context of the stmt to update the range. Now that said, the update issue is primarily within the cache. if we are updating and the BB isn't set, we could simply just pick up the global valu= e.=20 Patch is attached, and pre-approved if you want to use it.=