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/113334] wrong code with _BitInt() shift at -O0
Date: Fri, 12 Jan 2024 10:24:17 +0000	[thread overview]
Message-ID: <bug-113334-4-8jBA8rPVtl@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-113334-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113334

--- Comment #2 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:c75579169eba269a7c339d80b5ac0239f36a58b3

commit r14-7182-gc75579169eba269a7c339d80b5ac0239f36a58b3
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Jan 12 11:23:27 2024 +0100

    lower-bitint: Fix up handling of unsigned INTEGER_CSTs operands with lots
of 1s in the upper bits [PR113334]

    For INTEGER_CST operands, the code decides if it should emit the whole
    INTEGER_CST into memory, or if there are enough upper bits either all 0s
    or all 1s to warrant an optimization, where we use memory for lower limbs
    or even just an INTEGER_CST for least significant limb and fill in the
    rest of limbs with 0s or 1s.  Unfortunately when not using
    bitint_min_cst_precision, the code was using tree_int_cst_sgn (op) < 0
    to determine whether to fill in the upper bits with 1s or 0s.  That is
    incorrect for TYPE_UNSIGNED INTEGER_CSTs which have higher limbs full of
    ones, we really want to check here whether the most significant bit is
    set or clear.

    Fixed thusly.

    2024-01-12  Jakub Jelinek  <jakub@redhat.com>

            PR tree-optimization/113334
            * gimple-lower-bitint.cc (bitint_large_huge::handle_operand): Use
            wi::neg_p (wi::to_wide (op)) instead of tree_int_cst_sgn (op) < 0
            to determine if number should be extended by all ones rather than
zero
            extended.

            * gcc.dg/torture/bitint-46.c: New test.

  parent reply	other threads:[~2024-01-12 10:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-11 12:26 [Bug tree-optimization/113334] New: " zsojka at seznam dot cz
2024-01-11 16:53 ` [Bug tree-optimization/113334] " jakub at gcc dot gnu.org
2024-01-12 10:24 ` cvs-commit at gcc dot gnu.org [this message]
2024-01-12 10:28 ` jakub at gcc dot gnu.org
2024-01-16  0:35 ` pinskia 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-113334-4-8jBA8rPVtl@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).