From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-29.smtpout.orange.fr [80.12.242.29]) by sourceware.org (Postfix) with ESMTPS id DE3693858C36; Tue, 30 Jan 2024 10:38:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DE3693858C36 Authentication-Results: sourceware.org; dmarc=pass (p=none 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 DE3693858C36 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=80.12.242.29 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706611103; cv=none; b=JPDepcEeBSkmIvKdo/ZBoff7H4etJKL0TX4XVvd09uRZEck2UiGsmYECWGNNL7MvcqbCp44J6H1yDstpWUw8ChYCyeCyKUNUStbVEZvFC5LdW7b6uZmcFiU05b/YBqruJMJurzzFlvphWP8J8HRcLfhl6vdJK0yy9XOw8rfwxk0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706611103; c=relaxed/simple; bh=Rpo5wn8OsrnKHQRAvJw+VNAcPFAidemtnqsNhwP4UpE=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To; b=nnj9MtREAjvFIa2JP32onRKPq9pdfykY2KJz5nYRmzh2rZVCaBf/Y2gkzLaOUeO0GEc0YL5cZS1yA9VtzNSnyyu1YrCW9dwHQgfhaKS9rF1q/DfvlPp98keW5PP48Z+yPFsx/So8FLSNVWWzGWY7L1mA4mX1g7vpSrQ7U9k87nk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from [192.168.1.13] ([86.215.161.51]) by smtp.orange.fr with ESMTPA id UlVKrUW61zTWPUlVQrZ4Nt; Tue, 30 Jan 2024 11:38:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.fr; s=t20230301; t=1706611099; bh=AOIpRbUH6EPkUw1co7/o0AgtpEto3PuntZR2nVVxS6A=; h=Date:From:Subject:To:Cc:References:In-Reply-To; b=MybsKFVagDLwWT3gYV+44afwuGGW/z1iXQZ5inRsREXuwkLwKwPX90+2CjkuvGAR+ PgtbwQJ0+VYr/JapaRqLw/v251+Qh6VD5afaWMKNUeK2EpdXHzq637X6ql74I4NKn9 F8UDdB6qg4a2rMKm7YO4Pn1Qgu3/sDWWreO4u6pamq3N0IZgisq/VcyeUFHLKDjdtb 0uKB1i9ia2tnyslev4R89FZjagOT+jcR6vAj9f7LnY3pq0yPCBis5GX1xUNsiWvuOK Kg7n3BVuAvP4tVLFBWRl/mD4oD1ehwflvShi8H3vkZnR1quxgTeVWOBcL0lQgijhb6 3Mux789a2g3hA== X-ME-Helo: [192.168.1.13] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Tue, 30 Jan 2024 11:38:19 +0100 X-ME-IP: 86.215.161.51 Message-ID: <50f2a7c0-55af-4079-9f6f-41dc6497c234@orange.fr> Date: Tue, 30 Jan 2024 11:38:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Mikael Morin Subject: Re: [PATCH] Fortran: use name of array component in runtime error message [PR30802] 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> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.2 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,JMQ_SPF_NEUTRAL,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 29/01/2024 à 21:50, Harald Anlauf a écrit : > Am 29.01.24 um 18:25 schrieb Harald Anlauf: >> I was talking about the generated format strings of runtime error >> messages. >> >> program p >>    implicit none >>    type t >>       real :: zzz(10) = 42 >>    end type t >>    class(t), allocatable :: xx(:) >>    integer :: j >>    j = 0 >>    allocate (t :: xx(1)) >>    print *, xx(1)% zzz(j) >> end >> >> This is generating the following error at runtime since at least gcc-7: >> >> Fortran runtime error: Index '0' of dimension 1 of array 'xx%_data%zzz' >> below lower bound of 1 > > Of course this is easily suppressed by: > > diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc > index 1e0d698a949..fa0e00a28a6 100644 > --- a/gcc/fortran/trans-array.cc > +++ b/gcc/fortran/trans-array.cc > @@ -4054,7 +4054,8 @@ gfc_conv_array_ref (gfc_se * se, gfc_array_ref * > ar, gfc_expr *expr, >      { >        if (ref->type == REF_ARRAY && &ref->u.ar == ar) >          break; > -      if (ref->type == REF_COMPONENT) > +      if (ref->type == REF_COMPONENT > +          && strcmp (ref->u.c.component->name, "_data") != 0) >          { >            strcat (var_name, "%%"); >            strcat (var_name, ref->u.c.component->name); > > > I have been contemplating the generation the full chain of references as > suggested by Mikael and supported by NAG. To be clear, my suggestion was to have the question marks (or dashes, dots, stars, whatever) literally in the array reference, without the actual values of the array indexes. 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 > The main issue is: how do I easily generate that call? > gfc_trans_runtime_check is a vararg function, but what I would rather > have is a function that takes either a (chained?) list of trees or > an array of trees holding the (co-)indices of the reference. > > Is there an example, or a recommendation which variant to prefer? > None that I know. For a scalarized expression, the values are present (among others) in the gfc_loopinfo::ss linked list, maybe just use that? In any case, I agree it would be nice to have, but it would probably be a non-negligible amount of new error-prone code; I would rather not attempt this during the stage4 stabilization phase as we are currently.