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/112843] during GIMPLE pass: bitintlower ICE: SIGSEGV in ranger_cache::range_of_expr (gimple-range-cache.cc:1204) with _BitInt() at -O1
Date: Tue, 05 Dec 2023 08:48:23 +0000	[thread overview]
Message-ID: <bug-112843-4-nSU5FY6vbY@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-112843-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #10 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:1a84af19cd18730477dbceaebc45466c3fd77b60

commit r14-6138-g1a84af19cd18730477dbceaebc45466c3fd77b60
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Dec 5 09:45:40 2023 +0100

    lower-bitint: Make temporarily wrong IL less wrong [PR112843]

    As discussed in the PR, for the middle (on x86-64 65..128 bit) _BitInt
    types like
      _1 = x_4(D) * 5;
    where _1 and x_4(D) have _BitInt(128) type and x is PARM_DECL, the bitint
    lowering pass wants to replace this with
      _13 = (int128_t) x_4(D);
      _12 = _13 * 5;
      _1 = (_BitInt(128)) _12;
    where _13 and _12 have int128_t type and the ranger ICEs when the IL is
    temporarily invalid:
    during GIMPLE pass: bitintlower
    pr112843.c: In function âfooâ:
    pr112843.c:7:1: internal compiler error: Segmentation fault
        7 | foo (_BitInt (128) x, _BitInt (256) y)
          | ^~~
    0x152943f crash_signal
            ../../gcc/toplev.cc:316
    0x25c21c8 ranger_cache::range_of_expr(vrange&, tree_node*, gimple*)
            ../../gcc/gimple-range-cache.cc:1204
    0x25cdcf9 fold_using_range::range_of_range_op(vrange&,
gimple_range_op_handler&, fur_source&)
            ../../gcc/gimple-range-fold.cc:671
    0x25cf9a0 fold_using_range::fold_stmt(vrange&, gimple*, fur_source&,
tree_node*)
            ../../gcc/gimple-range-fold.cc:602
    0x25b5520 gimple_ranger::update_stmt(gimple*)
            ../../gcc/gimple-range.cc:564
    0x16f1234 update_stmt_operands(function*, gimple*)
            ../../gcc/tree-ssa-operands.cc:1150
    0x117a5b6 update_stmt_if_modified(gimple*)
            ../../gcc/gimple-ssa.h:187
    0x117a5b6 update_stmt_if_modified(gimple*)
            ../../gcc/gimple-ssa.h:184
    0x117a5b6 update_modified_stmt
            ../../gcc/gimple-iterator.cc:44
    0x117a5b6 gsi_insert_after(gimple_stmt_iterator*, gimple*,
gsi_iterator_update)
            ../../gcc/gimple-iterator.cc:544
    0x25abc2f gimple_lower_bitint
            ../../gcc/gimple-lower-bitint.cc:6348

    What the code does right now is, it first creates a new SSA_NAME (_12
    above), adds the
      _1 = (_BitInt(128)) _12;
    stmt after it (where it crashes, because _12 has no SSA_NAME_DEF_STMT yet),
    then sets lhs of the previous stmt to _12 (this is also temporarily
    incorrect, there are incompatible types involved in the stmt), later on
    changes also operands and finally update_stmt it.

    The following patch instead changes the lhs of the stmt before adding the
    cast after it.  The question is if this is less or more wrong temporarily
    (but the ICE is gone).  In addition to that the patch moves the operand
    adjustments before the lhs adjustment.

    The reason I tweaked the lhs first is that it then just uses gimple_op and
    iterates over all ops, if that is done before lhs it would need to special
    case which op to skip because it is lhs (I'm using gimple_get_lhs for the
    lhs, but this isn't done for GIMPLE_CALL nor GIMPLE_PHI, so GIMPLE_ASSIGN
    or say GIMPLE_GOTO etc. are the only options).

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

            PR tree-optimization/112843
            * gimple-lower-bitint.cc (gimple_lower_bitint): Change lhs of stmt
            to lhs2 before building and inserting lhs = (cast) lhs2;
assignment.
            Adjust stmt operands before adjusting lhs.

            * gcc.dg/bitint-47.c: New test.

  parent reply	other threads:[~2023-12-05  8:48 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-04 11:45 [Bug tree-optimization/112843] New: " zsojka at seznam dot cz
2023-12-04 14:17 ` [Bug tree-optimization/112843] " jakub at gcc dot gnu.org
2023-12-04 14:26 ` rguenth at gcc dot gnu.org
2023-12-04 14:28 ` rguenth at gcc dot gnu.org
2023-12-04 14:32 ` rguenth at gcc dot gnu.org
2023-12-04 16:02 ` amacleod at redhat dot com
2023-12-04 16:13 ` jakub at gcc dot gnu.org
2023-12-04 16:39 ` amacleod at redhat dot com
2023-12-04 16:57 ` jakub at gcc dot gnu.org
2023-12-04 18:19 ` amacleod at redhat dot com
2023-12-05  8:48 ` cvs-commit at gcc dot gnu.org [this message]
2023-12-06  7:28 ` cvs-commit at gcc dot gnu.org
2023-12-06  7:57 ` rguenth 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-112843-4-nSU5FY6vbY@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).