From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id C975E386103C for ; Mon, 4 Jan 2021 21:19:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org C975E386103C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-462-FFmx02WlPhOrSf6R3t9gaA-1; Mon, 04 Jan 2021 16:19:35 -0500 X-MC-Unique: FFmx02WlPhOrSf6R3t9gaA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id D62091927801; Mon, 4 Jan 2021 21:19:34 +0000 (UTC) Received: from localhost.localdomain (ovpn-114-95.phx2.redhat.com [10.3.114.95]) by smtp.corp.redhat.com (Postfix) with ESMTP id 93A3B60BE5; Mon, 4 Jan 2021 21:19:34 +0000 (UTC) Subject: Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog) To: Jakub Jelinek Cc: Xi Ruoyao , gcc-patches@gcc.gnu.org References: <4df733093ede4a3cc5dcb2688dcc9a2e5be4b721.camel@mengyan1223.wang> <184fa89ee34af9c3b13e99513a10aed1bd7c88af.camel@mengyan1223.wang> <20210104210018.GD725145@tucnak> From: Jeff Law Message-ID: <7825bdca-1a9a-90dc-671f-1dda98e1f5f4@redhat.com> Date: Mon, 4 Jan 2021 14:19:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210104210018.GD725145@tucnak> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jan 2021 21:19:38 -0000 On 1/4/21 2:00 PM, Jakub Jelinek wrote: > On Mon, Jan 04, 2021 at 01:51:59PM -0700, Jeff Law via Gcc-patches wrote: >>> Sorry, I forgot to include the ChangeLog: >>> >>> gcc/ChangeLog: >>> >>> 2020-12-31 Xi Ruoyao >>> >>> PR target/98491 >>> * config/mips/mips.c (mips_symbol_insns): Do not use >>> MSA_SUPPORTED_MODE_P if mode is MAX_MACHINE_MODE. >> So I absolutely agree the current code is wrong as it does an out of >> bounds array access. >> >> >> Would it be better to instead to change MSA_SUPPORTED_MODE_P to evaluate >> to zero if MODE is MAX_MACHINE_MODE?  That would protect all the uses of >> MSA_SUPPORTED_MODE_P.    Something like this perhaps? > But MAX_MACHINE_MODE is the one past last valid mode, I'm not aware of > any target that would protect all macros that deal with modes that way. > > So, perhaps best would be stop using the MAX_MACHINE_MODE as magic value > for that function and instead use say VOIDmode that shouldn't normally > appear either? I think we have to allow VOIDmode because constants don't necessarily have modes.   And I certainly agree that using MAX_MACHINE_MODE like this is ugly and error prone (as we can see from the BZ). I also couldn't convince myself that the code and comments were actually consistent, particularly for MSA targets which the comment claims can never handle constants for ld/st (and thus should be returning 0 for MAX_MACHINE_MODE).  Though maybe mips_symbol_insns_1 ultimately handles that correctly. > > But I don't really see anything wrong on the mips_symbol_insns above > change either. Me neither.  I'm just questioning if bullet-proofing in the MSA_SUPPORTED_MODE_P would be a better option.  While I've worked in the MIPS port in the past, I don't really have any significannt experience with the MSA support. jeff