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.

  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: link
Be 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).