From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtpbgsg2.qq.com (smtpbgsg2.qq.com [54.254.200.128]) by sourceware.org (Postfix) with ESMTPS id 2F9A43858D37 for ; Wed, 24 May 2023 01:57:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2F9A43858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivai.ai Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivai.ai X-QQ-mid: bizesmtp83t1684893450tmkl08r8 Received: from rios-cad5.localdomain ( [58.60.1.11]) by bizesmtp.qq.com (ESMTP) with id ; Wed, 24 May 2023 09:57:29 +0800 (CST) X-QQ-SSF: 01400000000000F0R000000A0000000 X-QQ-FEAT: 3M0okmaRx3gSbqUlMdelevC/IRHHr4bIgmQzTT3+OYiUyP91g0LlsQBkVLZy8 3gTj2AqQvPfqbqbJ3gOVaK3EpDtHUt3tj5vCw9UMsDVMej1RmTIqOB7OlUHmquGksLTulFo Q+Z2au/ykc2hYGIvDamGe0jw2dQwaNdB0h9RQatfYyKlO+VD32LPmVMfvxFap5LULNqTDno 0IvGQ7WpFYtCqgnbA4MFCrK1sGIzHVyGKp8EsOihftk5iu0Qfx7D91asKHLYJIA0TEPD8ly vonCrBM5iVUfEou/z2cnM08J+GVtWb908p7HGnq33Ugto4QS94LGrTiT/ALS8KBNJkwKLwy 48F/rbxyhEa6EGVxbA0eWVWw1gbTt+vpDnZZ2u46b4af+w2wqfKTlmk1R/2HhnYZ7XKOQD0 X-QQ-GoodBg: 2 X-BIZMAIL-ID: 18079392677378202464 From: juzhe.zhong@rivai.ai To: gcc-patches@gcc.gnu.org Cc: kito.cheng@gmail.com, kito.cheng@sifive.com, palmer@dabbelt.com, palmer@rivosinc.com, jeffreyalaw@gmail.com, rdapp.gcc@gmail.com, Juzhe-Zhong Subject: [PATCH] RISC-V: Fix incorrect code of touching inaccessible memory address Date: Wed, 24 May 2023 09:57:27 +0800 Message-Id: <20230524015727.1157568-1-juzhe.zhong@rivai.ai> X-Mailer: git-send-email 2.36.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:rivai.ai:qybglogicsvrgz:qybglogicsvrgz7a-one-0 X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: From: Juzhe-Zhong For VLMAX situation, rtx len = ops[m_op_num] is incorrect since the last element the ops array should be ops[m_op_num - 1]; I notice this issue when I am debugging code. This is a code bug even though the following codes will hide this issue. We still should need this minor fix. Built && Regression PASSed. Ok for trunk? gcc/ChangeLog: * config/riscv/riscv-v.cc: Fix bug of touching inaccessible memory. --- gcc/config/riscv/riscv-v.cc | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc index fa61a850a22..a0992773644 100644 --- a/gcc/config/riscv/riscv-v.cc +++ b/gcc/config/riscv/riscv-v.cc @@ -169,7 +169,11 @@ public: if (m_needs_avl_p) { - rtx len = ops[m_op_num]; + /* The variable "m_op_num" means the real operation operands except VL + operand. For VLMAX patterns (no VL operand), the last operand is + ops[m_op_num -1]. Wheras for non-VLMAX patterns, the last operand is + VL operand which is ops[m_op_num]. */ + rtx len = NULL_RTX; if (m_vlmax_p) { if (const_vlmax_p (m_dest_mode)) @@ -185,6 +189,20 @@ public: len = gen_reg_rtx (Pmode); emit_vlmax_vsetvl (m_dest_mode, len); } + else + { + /* According to LRA mov pattern in vector.md. The VL operand is + always the last operand. */ + gcc_assert (ops[m_op_num]); + len = ops[m_op_num]; + } + } + else + { + /* For non-VLMAX patterns. The VL operand is always the last + * operand. */ + gcc_assert (ops[m_op_num]); + len = ops[m_op_num]; } add_input_operand (len, Pmode); } -- 2.36.3