From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id AD9373858407; Fri, 22 Mar 2024 08:24:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AD9373858407 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1711095845; bh=JTw6Wm31h48zHF7+zYzHmh2qtc02ylLTTXNy2+ln47k=; h=From:To:Subject:Date:In-Reply-To:References:From; b=xToREqlDMQAuLucf2Qs1i4NCQSu0T5UOng5FPGNVPIp9kXXS6PCib4Ff7S8HlFpAq z9raVNpaQ1K6x6UbwYLJESPlJ36j8tPApwfD+1KUWlxyZTyv4Q5oLM8LkiRX0wJh5C fkd8+8CTIEem5TjEueu1WWvk+b/kjbLgt6oPIwAM= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/114405] ICE: in min_value, at wide-int.cc:344 with _BitInt() bitfield arithmetics Date: Fri, 22 Mar 2024 08:23:32 +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: cvs-commit at gcc dot gnu.org 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: 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=3D114405 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:982250b230967776f0da708a1572b78a38561e08 commit r14-9609-g982250b230967776f0da708a1572b78a38561e08 Author: Jakub Jelinek Date: Fri Mar 22 09:22:04 2024 +0100 bitint: Some bitint store fixes [PR114405] The following patch fixes some bugs in the handling of stores to large/= huge _BitInt bitfields. In the first 2 hunks we are processing the most significant limb of the actual type (not necessarily limb in the storage), and so we know it is either partial or full limb, so [1, limb_prec] bits rather than [0, limb_prec - 1] bits as the code actually assumed. So, those 2 spots are fixed by making sure if tprec is a multiple of limb_prec we actually use limb_prec bits rather than 0. Otherwise, it e.g. happily could create and use 0 precision INTEGER_TYPE even when it actually should have processed 64 bits, or for non-zero bo_bit could handle just say 1 bit rather than 64 bits plus 1 bit in the last hunk spot. In the last hunk we are dealing with the extra bits in the last storage limb, and the code was e.g. happily creating 65 bit precision INTEGER_T= YPE, even when we really should use 1 bit precision in that case. Also, it used a wrong offset in that case. The large testcase covers all these cases. 2024-03-22 Jakub Jelinek PR tree-optimization/114405 * gimple-lower-bitint.cc (bitint_large_huge::lower_mergeable_st= mt): Set rprec to limb_prec rather than 0 if tprec is divisible by limb_prec. In the last bf_cur handling, set rprec to (tprec + bo_bit) % limb_prec rather than tprec % limb_prec and use just rprec instead of rprec + bo_bit. For build_bit_field_ref offset, divide (tprec + bo_bit) by limb_prec rather than just tprec. * gcc.dg/torture/bitint-66.c: New test.=