From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-30.smtpout.orange.fr [80.12.242.30]) by sourceware.org (Postfix) with ESMTPS id E498C385E445; Fri, 15 Mar 2024 19:29:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E498C385E445 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E498C385E445 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=80.12.242.30 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710530994; cv=none; b=yB36SWhc1MqoZwdxMkr8/oIvzbTPZAlx6s5lnE0N+CZ0jVGAsSvySmVGtK8W45/6PA0Pp369/bSdEvf5FIe/TPsgoHswNsTvhS8Ahwxi9ZjRclJTfIhK03wL2HOsN33NV+FJplmMDNor4Euz9Zdmcvqk69hchBHcAi/VFBE7xuA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710530994; c=relaxed/simple; bh=y0gDLVA6Id1IN6lHcNoqpp6OiQ/ZrhcEruai2OWuwRw=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Nu/+KYoujx8B+AztgCOx+5SDGm/QS6+7rtwptfpf+4tYPPRp78EhUuTLT7jCYhgC/Xgh0SQy9KrIkdi0jiVWI7sHSnr9dSJyhQqkRPJ1lX/e0dRBI8wBMgpszz6wGtRPi+WcDb8aK/sGEO5G7lXoGVZxl8xQ1OYTy3JheBxneUg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.1.19] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id lDFMrS8e1Ld63lDFMr2oPF; Fri, 15 Mar 2024 20:29:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1710530982; bh=mtwCnhoRLY9m15RTKb2qqKnjQMiRPwDYFj0ughQvHuk=; h=Message-ID:Date:MIME-Version:Subject:To:From; b=rvikSUd5/B3ZDv258/ziRPJRFlSXb1Y3N9VGozQJG2LB72up1rXHTT8vGoVnmqYGu OGIbbVJOF/HW2pIiGcwEg0aHSkHoHPG9hIU6P8RbIFZxQNSqhtvm/9iIAuFlLdNemV I134WOQcbv9qQoFmnzztaed3CEiD+6urroqiersMYyIbEcR6Z0sRZCea/LZgUsDMxK 4GCRZQoKxIjAba9ZSm74sqMc8RgY/zTDTnRhulw/WMItdb6gAMKqjtLawnaDAtuHJD lhWO9995Boxv/ecC9JnpBX1tEj0puZCs3pMDEZUdNOZNpov+E83CRAESTxAqUewOIT hkWAwvPuMdGAA== X-ME-Helo: [192.168.1.19] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Fri, 15 Mar 2024 20:29:42 +0100 X-ME-IP: 86.215.161.51 Message-ID: <998a971e-1614-42b8-87c7-6c85c33b16e6@orange.fr> Date: Fri, 15 Mar 2024 20:29:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH, v2] Fortran: use name of array component in runtime error message [PR30802] Content-Language: en-US To: Harald Anlauf , sgk@troutmask.apl.washington.edu Cc: fortran , gcc-patches References: <67c77b44-79cb-4029-b59a-c92dfad15fa9@orange.fr> <86888cc5-3650-4044-b67d-89aab1631753@gmx.de> <70fc4304-74b4-4d8c-8172-9c3286bc9ada@gmx.de> <50f2a7c0-55af-4079-9f6f-41dc6497c234@orange.fr> <04f84bdb-4589-444a-93af-9e252908da93@orange.fr> <6d15efdc-cc99-4008-b0e7-9091a9cebced@orange.fr> From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Le 15/03/2024 à 18:26, Harald Anlauf a écrit : > Hi Mikael, > > On 3/15/24 17:31, Mikael Morin wrote: >> Le 10/03/2024 à 22:31, Harald Anlauf a écrit : >>> Dear all, >>> >>> after playing for some time with NAG and Intel, and an off-list >>> discussion with Jerry, I am getting more and more convinced that >>> simpler runtime error messages (also simpler to parse by a human) >>> are superior to awkward solutions.  This is also what Intel does: >>> use only the name of the array (component) in the message whose >>> indices are out of bounds. >>> >>> (NAG's solution appears also inconsistent for nested derived types.) >>> >>> So no x%z, or x%_data, etc. in runtime error messages any more. >>> >> That's a pity.  What about providing the root variable and the failing >> component only? >> >> ... dimension 1 of array component 'z...%x' above array bound ... >> >> The data reference doesn't look great, but it provides valuable (in my >> opinion) information. > > OK, that sounds interesting.  To clarify the options: > > - for ordinary array x it would stay 'x' > > - when z is a DT scalar, and z%x is the array in question, use 'z%x' >   (here z...%x would look strange to me) > Yes, the ellipsis would look strange to me as well. > - when z is a DT array, and x some component further down, 'z...%x' > This case also applies when z is a DT scalar and x is more than one level deep. > I would rather not make the error message text vary too much to avoid > to run into issues with translation.  Would it be fine with you to have > > ... dimension 1 of array 'z...%x' above array bound ... > > only? > OK, let's drop "component". > Anything else? > No, I think you covered everything. > Cheers, > Harald > >>> Please give it a spin... >>> >>> Regtested on x86_64-pc-linux-gnu.  OK for mainline? >>> >>> Thanks, >>> Harald >>> >>> >>> On 1/30/24 11:46, Mikael Morin wrote: >>>> Le 30/01/2024 à 11:38, Mikael Morin a écrit : >>>>> >>>>> Another (easier) way to clarify the data reference would be rephrasing >>>>> the message so that the array part is separate from the scalar part, >>>>> like so (there are too many 'of', but I lack inspiration): >>>>> Index '0' of dimension 1 of component 'zz' of element from 'x1%vv' >>>>> below lower bound of 1 >>>>> >>>> This has the same number of 'of' but sounds better maybe: >>>> Out of bounds accessing component 'zz' of element from 'x1%yy': index >>>> '0' of dimension 1 below lower bound of 1 >>>> >> >> >