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 798283858D1E for ; Tue, 19 Jul 2022 21:34:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 798283858D1E Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1oDur7-0001bu-AC for fortran@gcc.gnu.org; Tue, 19 Jul 2022 23:34:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: fortran@gcc.gnu.org From: Harald Anlauf Subject: Re: [PATCH] Fortran: error recovery on invalid array reference of non-array [PR103590] Date: Tue, 19 Jul 2022 23:34:07 +0200 Message-ID: <091e5ede-b816-0ba8-470c-7c648f9b2868@gmx.de> References: <0342ad62-3f9c-4fbb-bd00-f4d4a6b49fc7@orange.fr> <26b7b8f2-fd97-058c-40e1-d16b4e26880e@gmx.de> 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.11.0 Content-Language: en-US In-Reply-To: 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 autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 19 Jul 2022 21:34:16 -0000 Hi Mikael, Am 19.07.22 um 22:53 schrieb Mikael Morin: > It could be anything better than the (unhelpfull) internal error it is > replacing. > I suggest for example "Invalid array reference of a non-array entity at > %L". yes, that's much better! The attached updated patch uses this. Committed: r13-1757-gf838d15641d256e21ffc126c3277b290ed743928 >> gfortran's behavior during error handling is difficult to understand. >> While the proposed new error message is emitted for associate_54.f90, >> it never makes it far enough for the testcase of the present PR >> (associate_59.f90). >> > Indeed.  We try to match several types of statement one after the other, > and each failed match can possibly register an error.  But it is emitted > only if all have failed (see gfc_error_check).  There is no choice of > the best error; the last one registered wins. > > This buffering behavior is controlled by calls to gfc_buffer_error(...). >  Error handling during resolution doesn’t need to delay error reporting > as far as I know, and the calls to gfc_buffer_error (false) seem to > correctly disable buffering at the end of every call to next_statement. >  I don’t know why it remains active in this case. > Alright, I should try to remember this and take a closer look next time I get confused about not getting the error message I wanted... Thanks, Harald From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by sourceware.org (Postfix) with ESMTPS id 905A33857C44; Tue, 19 Jul 2022 21:34:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 905A33857C44 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.178.29] ([79.251.12.112]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N0oG5-1nHZVL2DuX-00wo52; Tue, 19 Jul 2022 23:34:22 +0200 Message-ID: <091e5ede-b816-0ba8-470c-7c648f9b2868@gmx.de> Date: Tue, 19 Jul 2022 23:34:07 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH] Fortran: error recovery on invalid array reference of non-array [PR103590] Content-Language: en-US To: Mikael Morin , fortran@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org Newsgroups: gmane.comp.gcc.fortran,gmane.comp.gcc.patches References: <0342ad62-3f9c-4fbb-bd00-f4d4a6b49fc7@orange.fr> <26b7b8f2-fd97-058c-40e1-d16b4e26880e@gmx.de> From: Harald Anlauf In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:7ASLFd84F5TkeiFpEO+2N50oDwj/vXWmW325BSgXmaaN0pPFk+P Wkewa94bzhXDkIGqc8PQIt8xkFOzDJUlbqJR4+Zw8vkCbGJ5tVBOJk57Y3wjUQ07GXaLq6C h1Q75bn9UepqTbjMjSALxyAD79exA+QAfTQRFuQgPuNFjC8/1AshdGfq+F/YZ8Kxt4Z9l4f u+gfmn8lzCHND+gIss6eA== X-UI-Out-Filterresults: notjunk:1;V03:K0:IaCJmZZEPDc=:vi9Qezi3PVGdZNZh9+f++3 kXDooyo1qYGp+faGOasceUs16uDt8I6RfqfEBAUr8+NE1h1rve/95dSAa40Q3l3UceL8oQkZS zC78sHsYRO2urBvBSkGpEhvqppZHqA0F3jZi6J3tjXrkPndp+UcDn1VglEO9opQmI/9dBsaHi FW9fLMPFpvcJQ+FmmliYSIUSNNPxVa5u81CGh7ZUV/xA1r9icBxhTCQHM8FU1qrCu59Vsl1Vu dlpy+77/f2m58FxwRJ0OWC8HjG/zl9JcyH5rnFdSAfdc3cOtLy7VgrIK+m20xH7pSAfsoxKpV rJjA/E7+X/FVtL8M3qMkEJb3qFx1ZNJMERAYL43CY7UitjC8PLOSDldyJUw2/DxaqAC/6JvwS fXWyOUzil56KhJEJQt4I1/QuxgDCBHQmYz3RRWW/6B8I3JFHG20vQMmHSs4cOUwgLtwzgX3hX vTuQ7UGkeW6kPlm6+HpGg3yHidUnN2MJjA7f8auFLkcNA25nFEuRd5AY+vzsq6CLpv/yKPvJv nrm2KCQIwztDecnvXGDVe+WXlw5Y2kM7Gyen1n9QAukG84of+YYSd9OrtvHwz7HdJiPa6ggpq pnO1gVmw0LLircNtwCmierxOlo+fepceIeZYLfK0u8bENLpAdey34KB2Lxskd1Dw44mmlAJfh AakKB+aIS4T0TuRNaBYkMfTkrxa2hx1NMD5xDjRbN7mNyhVCjWrCtqBWfBOVkPp9ZJUxk5OsY TIBJVS1KSSd+smFJ8G8YVhhFBQozhJI3DSCra8qNCf7EsII2ZpT+veqCS2aIJyg9Ebtqwgd0j Gj45QgfSlVmucKMIkJl7csVNGlKEm9VTBbC+OJagWAFbz6yqLrRjsrBvVEBpzD0AvcNlgKYHA o8r7qKbPZmL3LV49O08Gd9DdiAif4eHGUBJVTsDgsBzarHx+wCtbeJEbdAQ520LdRy+Gnnk83 LNW+5vKLMMVzdGT78Wze9qbwIIqg7lzCGVuZJXgPVH3o7bEdv8uG4SmHInguxUG1lYUI3nsmN rhaIBJiaIgmwEbO8xG+wk3gEdm7qks9DNE/SzSk2srKZvg7f/GqLaXHOVKRr0TvntH53hEv9V CnjgWwUw9yMoN/tCNEV+T9anw5zuMiw7WPGjUnjKWZm4nuwNzSJd7Xbtw== X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Tue, 19 Jul 2022 21:34:26 -0000 Message-ID: <20220719213407.phcxo_QFN7rkMxBF_NYxdj5aRJrVw80C7JW1QX9Iw7s@z> Hi Mikael, Am 19.07.22 um 22:53 schrieb Mikael Morin: > It could be anything better than the (unhelpfull) internal error it is > replacing. > I suggest for example "Invalid array reference of a non-array entity at > %L". yes, that's much better! The attached updated patch uses this. Committed: r13-1757-gf838d15641d256e21ffc126c3277b290ed743928 >> gfortran's behavior during error handling is difficult to understand. >> While the proposed new error message is emitted for associate_54.f90, >> it never makes it far enough for the testcase of the present PR >> (associate_59.f90). >> > Indeed.=C2=A0 We try to match several types of statement one after the o= ther, > and each failed match can possibly register an error.=C2=A0 But it is em= itted > only if all have failed (see gfc_error_check).=C2=A0 There is no choice = of > the best error; the last one registered wins. > > This buffering behavior is controlled by calls to gfc_buffer_error(...). > =C2=A0Error handling during resolution doesn=E2=80=99t need to delay er= ror reporting > as far as I know, and the calls to gfc_buffer_error (false) seem to > correctly disable buffering at the end of every call to next_statement. > =C2=A0I don=E2=80=99t know why it remains active in this case. > Alright, I should try to remember this and take a closer look next time I get confused about not getting the error message I wanted... Thanks, Harald