From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by sourceware.org (Postfix) with ESMTPS id E19CC3858D32; Sun, 28 Jan 2024 21:43:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E19CC3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=troutmask.apl.washington.edu Authentication-Results: sourceware.org; spf=none smtp.mailfrom=troutmask.apl.washington.edu ARC-Filter: OpenARC Filter v1.0.0 sourceware.org E19CC3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=128.95.76.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706478221; cv=none; b=fBkLrL7Ppda9pM3Z/xWrvDLRBHhRb0y5+53Seb8qZtrAkhuiw3xeFSlGg0gKkFI0QFTx1JZI8XsqWYKtrlIeaHA5trHQ3muB3w4bcbevyTpeCaGmdqCzfo0uic4hgkRQb6Mgp9OL17YkkxqRxXyRDonVN77b1mob+c8URooiIjg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706478221; c=relaxed/simple; bh=YD+EfY+xX4UvbqXHZmLc/07Ng98RWziVWlv71yPJ4oE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=Gv+MRCcpaqGVFG4RGHpxpXZaAFetrmtu6/xYQKehGz6AgB8wTksG6dVeK9udUTnfZSRcdHiXa3D7ZQGSefw2OmRC1VbMvFkhQkSkFdbPNgJ2I0jiesFIgf571awWqa3XxymLQUIr+RUIYiVBqM4M8IJI3yBFtu4TszrqxkFvawI= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.17.1/8.17.1) with ESMTP id 40SLhcIO070745; Sun, 28 Jan 2024 13:43:38 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) DKIM-Filter: OpenDKIM Filter v2.10.3 troutmask.apl.washington.edu 40SLhcIO070745 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=troutmask.apl.washington.edu; s=troutmask; t=1706478218; bh=YD+EfY+xX4UvbqXHZmLc/07Ng98RWziVWlv71yPJ4oE=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=FuKGOdhcYzl97hYjx9w/jujgQcQVDeXIYks2V15Tc6FYoCovIODRzbLYOl6VBqyTM iwl9y9WbTowKORe4J1DhrbSLSsAPAhiXIbHoK6DNfegKVmgdB3QF4CIOHPQdxihRRq OldDwWzFqzFiOGVb6Hy/j1IXSQn61DffmqYuUUBHKCq0MNDRDRI5Gbb9CSbX9I3zV1 ILPYKeYQgUDbrzcChe7R7uCAdr+U28cb19Fp6hCMvutUHjQS4+0IG0otXr+uEPes+o nwaOoQtpWSORkbhWsS+UnmVK8H60n47sI0Mli0rDDhYf80aPFrUksXu/2LDOAT2m3u B0FZJpy3OBvJA== Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.17.1/8.17.1/Submit) id 40SLhb9M070744; Sun, 28 Jan 2024 13:43:37 -0800 (PST) (envelope-from sgk) Date: Sun, 28 Jan 2024 13:43:37 -0800 From: Steve Kargl To: Harald Anlauf Cc: Mikael Morin , fortran , gcc-patches Subject: Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802] Message-ID: Reply-To: sgk@troutmask.apl.washington.edu References: <67c77b44-79cb-4029-b59a-c92dfad15fa9@orange.fr> <86888cc5-3650-4044-b67d-89aab1631753@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86888cc5-3650-4044-b67d-89aab1631753@gmx.de> X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_INVALID,DKIM_SIGNED,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, Jan 28, 2024 at 08:56:24PM +0100, Harald Anlauf wrote: > > Am 28.01.24 um 12:39 schrieb Mikael Morin: > > Le 24/01/2024 à 22:39, Harald Anlauf a écrit : > > > Dear all, > > > > > > this patch is actually only a followup fix to generate the proper name > > > of an array reference in derived-type components for the runtime error > > > message generated for the bounds-checking code.  Without the proper > > > part ref, not only a user may get confused: I was, too... > > > > > > The testcase is compile-only, as it is only important to check the > > > strings used in the error messages. > > > > > > Regtested on x86_64-pc-linux-gnu.  OK for mainline? > > > > > > > the change proper looks good, and is an improvement.  But I'm a little > > concerned by the production of references like in the test x1%vv%z which > > could be confusing and is strictly speaking invalid fortran (multiple > > non-scalar components).  Did you consider generating x1%vv(?,?)%zz or > > x1%vv(...)%z or similar? > > yes, that seems very reasonable, given that this is what NAG does. > > We also have spurious %_data in some error messages that I'll try > to get rid off. > I haven't looked at the patch, but sometimes (if not always) things like _data are marked with attr.artificial. You might see if this will help with suppressing spurious messages. -- Steve