public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "pan2.li at intel dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471
Date: Mon, 17 Apr 2023 14:04:24 +0000	[thread overview]
Message-ID: <bug-109535-4-fQ4bQ4L2jG@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-109535-4@http.gcc.gnu.org/bugzilla/>

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

Li Pan <pan2.li at intel dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pan2.li at intel dot com

--- Comment #6 from Li Pan <pan2.li at intel dot com> ---
(In reply to rsandifo@gcc.gnu.org from comment #2)
> The assert in question fires if the pass creates an instruction
> whose pattern uses a register or memory and if the pass doesn't
> provide associated use information.  Let me know if it looks like
> a bug in rtl-ssa rather than a bug in the vsetvl pass.

Just sync with juzhe for the assertion failure. It tries to find the regno=8 in
the shared_uses=[0, 66, 67] in function_info::finalize_new_accesses. And then
it will hit the NOT_NULL assert.

While in the pass_vsetvl::cleanup_insns, it will clean up the AVL use similar
as below.

AVL regno 8
Before Uses Reg Nums => [0,8,66,67,]
After  Uses Reg Nums => [0,66,67,]

After vsetvl, the avl-related use, aka use Regno=8 will be removed, because the
instruction pattern in RVV will eliminate the dependencies of the operand.

Juzhe can help to correct me if any misleading or misunderstanding.

Thanks.

  parent reply	other threads:[~2023-04-17 14:04 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17  8:19 [Bug tree-optimization/109535] New: " malat at debian dot org
2023-04-17  8:23 ` [Bug target/109535] " malat at debian dot org
2023-04-17  8:49 ` rsandifo at gcc dot gnu.org
2023-04-17  9:19 ` juzhe.zhong at rivai dot ai
2023-04-17  9:26 ` juzhe.zhong at rivai dot ai
2023-04-17 10:00 ` kito at gcc dot gnu.org
2023-04-17 14:04 ` pan2.li at intel dot com [this message]
2023-04-17 14:54 ` kito at gcc dot gnu.org
2023-04-17 15:05 ` juzhe.zhong at rivai dot ai
2023-04-17 15:13 ` rsandifo at gcc dot gnu.org
2023-04-18  2:05 ` juzhe.zhong at rivai dot ai
2023-04-20 12:30 ` [Bug target/109535] [13/14] " kito at gcc dot gnu.org
2023-04-20 13:21 ` cvs-commit at gcc dot gnu.org
2023-04-20 14:30 ` juzhe.zhong at rivai dot ai
2023-04-20 15:02 ` malat at debian dot org
2023-04-20 22:44 ` juzhe.zhong at rivai dot ai
2023-04-21  1:46 ` juzhe.zhong at rivai dot ai
2023-05-04  3:22 ` [Bug target/109535] [13 regression] " cvs-commit at gcc dot gnu.org
2023-05-04  3:23 ` kito 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-109535-4-fQ4bQ4L2jG@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).