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/113491] ICE: SIGSEGV in make_ssa_name_fn (tree-ssanames.cc:354) at -Os with _BitInt() used as switch control expression Date: Sat, 20 Jan 2024 11:37:24 +0000 [thread overview] Message-ID: <bug-113491-4-J8qVLPOsBO@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-113491-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113491 --- 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:291e00e2d88a352f46cd539e3c5785982dc3fdd9 commit r14-8302-g291e00e2d88a352f46cd539e3c5785982dc3fdd9 Author: Jakub Jelinek <jakub@redhat.com> Date: Sat Jan 20 12:35:38 2024 +0100 tree-switch-conversion: Bugfixes for _BitInt [PR113491] The following patch fixes various issues with large/huge _BitInt used as switch expressions. In particular: 1) the indexes in CONSTRUCTORs shouldn't be types with precision larger than sizetype precision, varasm uses wi::to_offset on those and too large indexes ICE; we've already checked earlier that the cluster is at most sizetype bits and arrays can't be larger than that anyway 2) some spots were using SCALAR_INT_TYPE_MODE or lang_hooks.types.type_for_mode on TYPE_MODE to determine types to use, that obviously doesn't work for the large/huge BITINT_TYPE 3) like the recent change in the C FE, this patch makes sure we don't create ARRAY_REFs with indexes with precision above sizetype precision, because bitint lowering isn't prepared for that and because the indexes can't be larger than sizetype anyway; the subtraction of the cluster minimum from the index obviously needs to be done in unsigned __int128 or large/huge BITINT_TYPE, but then we cast to sizetype if the precision is larger than sizetype 2024-01-20 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/113491 * tree-switch-conversion.cc (switch_conversion::build_constructors): If elt.index has precision higher than sizetype, fold_convert it to sizetype. (switch_conversion::array_value_type): Return type if type is BITINT_TYPE with precision above MAX_FIXED_MODE_SIZE or with BLKmode. (switch_conversion::build_arrays): Use unsigned_type_for rather than lang_hooks.types.type_for_mode if utype is BITINT_TYPE with precision above MAX_FIXED_MODE_SIZE or with BLKmode. If utype has precision higher than sizetype, use sizetype as tidx type and fold_convert the subtraction to sizetype. * gcc.dg/torture/bitint-51.c: New test.
next prev parent reply other threads:[~2024-01-20 11:37 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-18 19:48 [Bug tree-optimization/113491] New: " zsojka at seznam dot cz 2024-01-19 15:47 ` [Bug tree-optimization/113491] " zsojka at seznam dot cz 2024-01-19 17:29 ` jakub at gcc dot gnu.org 2024-01-20 11:37 ` cvs-commit at gcc dot gnu.org [this message] 2024-01-20 11:38 ` jakub at gcc dot gnu.org 2024-01-20 17:11 ` 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-113491-4-J8qVLPOsBO@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: linkBe 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).