From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 8406E394FC3A for ; Wed, 16 Mar 2022 21:24:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8406E394FC3A Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1nUb7w-0005Ze-W5 for fortran@gcc.gnu.org; Wed, 16 Mar 2022 22:24:16 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: fortran@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH] fortran: Separate associate character lengths earlier [PR104570] Date: Wed, 16 Mar 2022 22:24:11 +0100 Message-ID: <4124db5c-55f0-0bb9-b352-2bdccba95f74@gmx.de> References: <4cce238d-5fdc-4a94-908b-9a1399193493@orange.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US In-Reply-To: <4cce238d-5fdc-4a94-908b-9a1399193493@orange.fr> Cc: gcc-patches@gcc.gnu.org X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2022 21:24:19 -0000 Message-ID: <20220316212411.sRn8WYMLjuPRyMnffrXRZ4PCRZNuBDQXPkvW0jwxdgQ@z> Hi Mikael, Am 14.03.22 um 19:28 schrieb Mikael Morin: > Hello, > > this workarounds the regression I introduced with the fix for pr104228. > The problem comes from the evaluation of character length for the > associate target (y) in the testcase. > The expression is non-scalar which is not supported at that point, as no > scalarization setup is made there. > > My initial direction to fix this was trying to modify the evaluation of > expressions so that the rank was ignored in the context of character > length evaluation. > That’s the patch I attached to the PR. > The patch I’m proposing here tries instead to avoid the need to evaluate > character length through sharing of gfc_charlen between symbols and > expressions. > I slightly prefer the latter direction, though I’m not sure it’s more > robust. > At least it passes regression testing, which proves some basic level of > goodness. > OK for master? I tried a few minor variations of the testcase, and they also seemed to work. The patch looks simple enough, so OK from my side. > Even if PR104570 is a 12 regression only, the PR104228 fix is targeted > at all the open branches so this one as well. > OK for 11/10/9? Yes, after giving it a short time on master to "burn in". Thanks for the patch! Harald