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 middle-end/112750] wrong code with _BitInt(256) and above with __builtin_sub_overflow_p() at -O0
Date: Fri, 01 Dec 2023 08:27:51 +0000	[thread overview]
Message-ID: <bug-112750-4-w0r0RRnubU@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-112750-4@http.gcc.gnu.org/bugzilla/>

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

--- 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:364332658ef790d09d250db39c5b13e27c3543f1

commit r14-6042-g364332658ef790d09d250db39c5b13e27c3543f1
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Fri Dec 1 09:25:45 2023 +0100

    lower-bitint: Fix _BitInt .{ADD,SUB}_OVERFLOW lowering [PR112750]

    The .{ADD,SUB}_OVERFLOW lowering is implemented by performing normal
    addition/subtraction (perhaps extended to even more bits than normally by
    continuing with extended values of operands after running of normal bits)
    and in addition to that trying to compute if certain sets of bits are
either
    all zero or all sign extensions of the least significant bit.

    That code is in a lot of cases guarded just by a single condition (which
    can be idx > startlimb, idx >= startlimb or idx == startlimb) or by
    2 conditions - if (idx >= startlimb) { if (idx == startlimb) ... else ... }
    Now, if_then_if_then_else when the second argument is NULL works just as
    if_then and sets m_gsi to be within the initially empty then block and that
is
    where we emit code for constant tidx startlimb + (cmp_code == GT_EXPR).
    But in the 2 conditions case, m_gsi is set to the initially empty else
    block, so using EQ_EXPR for the condition was incorrect (and strangely
    nothing in the testsuite caught that), because the code for extracting the
    lowest set of bits (i.e. when tidx is startlimb) is then done when idx
    is not startlimb rather than when it is.
    The following patch fixes that.

    Note, when developing the lowering, I was using gcov to make sure all code
    is covered by the testsuite with minimum exceptions, so no idea how this
    slipped out.

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

            PR middle-end/112750
            * gimple-lower-bitint.cc
(bitint_large_huge::lower_addsub_overflow):
            Use NE_EXPR rather than EQ_EXPR for g2 if !single_comparison and
            adjust probabilities.

            * gcc.dg/bitint-41.c: Use -std=c23 rather than -std=c2x.
            * gcc.dg/torture/bitint-43.c: Likewise.
            * gcc.dg/torture/bitint-44.c: Likewise.
            * gcc.dg/torture/bitint-45.c: New test.

  parent reply	other threads:[~2023-12-01  8:27 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-28 19:30 [Bug middle-end/112750] New: wrong code with _BitInt(256) and above and " zsojka at seznam dot cz
2023-11-30 10:20 ` [Bug middle-end/112750] wrong code with _BitInt(256) and above with " jakub at gcc dot gnu.org
2023-12-01  8:27 ` cvs-commit at gcc dot gnu.org [this message]
2023-12-01  8:28 ` 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-112750-4-w0r0RRnubU@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).