public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/98287] [10/11 Regression] ICE: in expand_expr_real_2, at expr.c:10000 with -O2 -fno-tree-ccp -fno-tree-forwprop Date: Tue, 15 Dec 2020 14:02:54 +0000 [thread overview] Message-ID: <bug-98287-4-le99KAjfz3@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-98287-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98287 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org Target Milestone|--- |10.3 Priority|P3 |P2 --- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Started with r10-2805-ge944354ec05891474b0d204c6c239c04ee7b527b I think this is another case of harmful folding after last veclower, in this case during vrp2. After last veclower we need to be careful not to introduce vector arithmetics that isn't supported by the target, as the expander doesn't have fallback for that, it relies on tree-vect-generic.c doing its job. So, either we need to guard all such match.pd etc. simplifications with checks whether the operations are supported on the vectors if we are after last veclower - in this particular case it is the x >> 1 << 1 optimization to x & { ~1 }, where the backend announces V1DImode >> and << but not AND, or schedule another veclower right before *.optimized dump to cover anything that got broken (or before isel and hope isel doesn't fold things?), or add fallback to the expander (the V1* vectors would be fairly easy, but anything else would be hard and ugly).
next prev parent reply other threads:[~2020-12-15 14:02 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-12-15 12:43 [Bug rtl-optimization/98287] New: " zsojka at seznam dot cz 2020-12-15 14:02 ` jakub at gcc dot gnu.org [this message] 2020-12-21 11:22 ` [Bug rtl-optimization/98287] " zsojka at seznam dot cz 2021-01-04 15:10 ` rguenth at gcc dot gnu.org 2021-02-01 12:39 ` jakub at gcc dot gnu.org 2021-02-03 8:10 ` cvs-commit at gcc dot gnu.org 2021-02-03 8:11 ` [Bug rtl-optimization/98287] [10 " jakub at gcc dot gnu.org 2021-03-19 23:28 ` cvs-commit at gcc dot gnu.org 2021-03-20 8:05 ` 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-98287-4-le99KAjfz3@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).