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/113120] during GIMPLE pass: bitintlower ICE: SIGSEGV with _BitInt() at -O2
Date: Wed, 10 Jan 2024 11:46:55 +0000	[thread overview]
Message-ID: <bug-113120-4-KoQDmAxWP7@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-113120-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #5 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:2611cdc329e0229330b228e441934f386d6d5ff7

commit r14-7095-g2611cdc329e0229330b228e441934f386d6d5ff7
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jan 10 12:46:00 2024 +0100

    sra: Partial fix for BITINT_TYPEs [PR113120]

    As changed in other parts of the compiler, using
    build_nonstandard_integer_type is not appropriate for arbitrary precisions,
    especially if the precision comes from a BITINT_TYPE or something based on
    that, build_nonstandard_integer_type relies on some integral mode being
    supported that can support the precision.

    The following patch uses build_bitint_type instead for BITINT_TYPE
    precisions.

    Note, it would be good if we were able to punt on the optimization
    (but this code doesn't seem to be able to punt, so it needs to be done
    somewhere earlier) at least in cases where building it would be invalid.
    E.g. right now BITINT_TYPE can support precisions up to 65535 (inclusive),
    but 65536 will not work anymore (we can't have > 16-bit TYPE_PRECISION).
    I've tried to replace 513 with 65532 in the testcase and it didn't ICE,
    so maybe it ran into some other SRA limit.

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

            PR tree-optimization/113120
            * tree-sra.cc (analyze_access_subtree): For BITINT_TYPE
            with root->size TYPE_PRECISION don't build anything new.
            Otherwise, if root->type is a BITINT_TYPE, use build_bitint_type
            rather than build_nonstandard_integer_type.

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

      parent reply	other threads:[~2024-01-10 11:46 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-23  7:46 [Bug tree-optimization/113120] New: " zsojka at seznam dot cz
2023-12-28 21:34 ` [Bug tree-optimization/113120] " pinskia at gcc dot gnu.org
2024-01-03 13:31 ` jakub at gcc dot gnu.org
2024-01-08 13:00 ` cvs-commit at gcc dot gnu.org
2024-01-08 13:02 ` jakub at gcc dot gnu.org
2024-01-10 11:46 ` cvs-commit at gcc dot gnu.org [this message]

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-113120-4-KoQDmAxWP7@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).