From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr [80.12.242.126]) by sourceware.org (Postfix) with ESMTPS id 8038B3858D1E for ; Tue, 19 Jul 2022 20:53:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8038B3858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.17] ([86.215.161.154]) by smtp.orange.fr with ESMTPA id DuDGoZn2bcdW9DuDNoPNs0; Tue, 19 Jul 2022 22:53:12 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Tue, 19 Jul 2022 22:53:12 +0200 X-ME-IP: 86.215.161.154 Message-ID: Date: Tue, 19 Jul 2022 22:53:01 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH] Fortran: error recovery on invalid array reference of non-array [PR103590] Content-Language: en-US To: Harald Anlauf , fortran@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org References: <0342ad62-3f9c-4fbb-bd00-f4d4a6b49fc7@orange.fr> <26b7b8f2-fd97-058c-40e1-d16b4e26880e@gmx.de> From: Mikael Morin In-Reply-To: <26b7b8f2-fd97-058c-40e1-d16b4e26880e@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, BODY_8BITS, FREEMAIL_FROM, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, 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 20:53:15 -0000 Le 19/07/2022 à 21:09, Harald Anlauf via Fortran a écrit : > Hi Mikael, > > Am 19.07.22 um 11:03 schrieb Mikael Morin: >> Hello, >> >> the principle looks good, but... >> >> Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit : >> >>> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc >>> index 2ebf076f730..dacd33561d0 100644 >>> --- a/gcc/fortran/resolve.cc >>> +++ b/gcc/fortran/resolve.cc >>> @@ -5004,7 +5004,11 @@ find_array_spec (gfc_expr *e) >>>        { >>>        case REF_ARRAY: >>>      if (as == NULL) >>> -      gfc_internal_error ("find_array_spec(): Missing spec"); >>> +      { >>> +        gfc_error ("Symbol %qs at %L has not been declared as an >>> array", >>> +               e->symtree->n.sym->name, &e->where); >> >> ... the error here only makes sense if the array reference follows a >> variable reference.  If it follows a derived type component reference, >> a slightly different error message would be more appropriate. > > how detailed or tailored should the error message be, or can > we just have a more generic message, like "Name at %L ...", > or "Invalid subscript reference at %L"?  We seem to not hit > that internal error very often... > 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". Cray’s words, or Intel’s, or your other propositions work as well. > > 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.