public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.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 [thread overview] Message-ID: <bug-114405-4-KSuKhwmUHu@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-114405-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114405 --- Comment #3 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:982250b230967776f0da708a1572b78a38561e08 commit r14-9609-g982250b230967776f0da708a1572b78a38561e08 Author: Jakub Jelinek <jakub@redhat.com> 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_TYPE, 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 <jakub@redhat.com> PR tree-optimization/114405 * gimple-lower-bitint.cc (bitint_large_huge::lower_mergeable_stmt): 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.
next prev parent reply other threads:[~2024-03-22 8:24 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-03-20 12:06 [Bug tree-optimization/114405] New: " zsojka at seznam dot cz 2024-03-20 13:24 ` [Bug tree-optimization/114405] " jakub at gcc dot gnu.org 2024-03-21 12:04 ` jakub at gcc dot gnu.org 2024-03-22 8:23 ` cvs-commit at gcc dot gnu.org [this message] 2024-03-22 8:25 ` jakub at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-114405-4-KSuKhwmUHu@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).