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 [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 3D5453857009 for ; Mon, 15 Feb 2021 23:16:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3D5453857009 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-355-RuV491-LM2aT75HnInVQMw-1; Mon, 15 Feb 2021 18:16:15 -0500 X-MC-Unique: RuV491-LM2aT75HnInVQMw-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 D3EBE106BB23; Mon, 15 Feb 2021 23:16:13 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-76.phx2.redhat.com [10.3.113.76]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9499360C15; Mon, 15 Feb 2021 23:16:10 +0000 (UTC) Subject: Re: [PATCH] MIPS: Fix PR target/98491 (ChangeLog) To: Xi Ruoyao , Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Robert Suchanek References: <4df733093ede4a3cc5dcb2688dcc9a2e5be4b721.camel@mengyan1223.wang> <184fa89ee34af9c3b13e99513a10aed1bd7c88af.camel@mengyan1223.wang> <20210104210018.GD725145@tucnak> <7825bdca-1a9a-90dc-671f-1dda98e1f5f4@redhat.com> From: Jeff Law Message-ID: Date: Mon, 15 Feb 2021 16:16:09 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: 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=-4.3 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, 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, 15 Feb 2021 23:16:19 -0000 On 2/12/21 7:17 AM, Xi Ruoyao wrote: > On 2021-01-11 01:01 +0800, Xi Ruoyao wrote: >> Hi Jeff and Jakub, >> >> On 2021-01-04 14:19 -0700, Jeff Law wrote: >>> 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. >> I can't understand the comment either.  To me it looks like it's possible to >> remove this "if (MSA_SUPPORTED_P (mode)) return 0;" >> >> CC Robert to get some help. > Happy new lunar year folks. > > I found a newer email address of Robert. Hope it is still being used. > > Could someone update MAINTAINERS file by the way? If you have an updated email address, I can reach out to Robert and see if he wants his entry updated or removed. Thanks, jeff