From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-17.smtpout.orange.fr [80.12.242.17]) by sourceware.org (Postfix) with ESMTPS id 21A5C3858D37 for ; Wed, 5 Oct 2022 08:51:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21A5C3858D37 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.174.255]) by smtp.orange.fr with ESMTPA id g07PoyQxWXaJmg07UoFEaA; Wed, 05 Oct 2022 10:51:14 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Wed, 05 Oct 2022 10:51:14 +0200 X-ME-IP: 86.215.174.255 Message-ID: <1bf3b7b5-39ac-0c94-256c-f739a4746a7b@orange.fr> Date: Wed, 5 Oct 2022 10:51:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: [PATCH] Fortran: error recovery for invalid types in array constructors [PR107000] Content-Language: fr, en-US To: Harald Anlauf , fortran , gcc-patches References: From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,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 List-Id: Hello Le 04/10/2022 à 23:19, Harald Anlauf via Fortran a écrit : > Dear all, > > we did not recover well from bad expressions in array constructors, > especially when there was a typespec and a unary '+' or '-', and > when the array constructor was used in an arithmetic expression. > > The attached patch introduces an ARITH_INVALID_TYPE that is used > when we try to recover from these errors, and tries to handle > all unary and binary arithmetic expressions. > In the PR, you noted an inconsistency in the error message reported, depending on the presence or lack of an operator. I'm not sure you saw the suggestion to do the following in the last message I posted: diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc index e6e35ef3c42..ed93ddb2882 100644 --- a/gcc/fortran/arith.cc +++ b/gcc/fortran/arith.cc @@ -1654,6 +1654,8 @@ eval_intrinsic (gfc_intrinsic_op op, else rc = reduce_binary (eval.f3, op1, op2, &result); + if (rc == ARITH_INVALID_TYPE) + goto runtime; /* Something went wrong. */ if (op == INTRINSIC_POWER && rc == ARITH_PROHIBIT) In the testcase, it improves the situation slightly. For example, from: > 9 | x = (1.0, 2.0) * [complex :: +'1'] ! { dg-error "Invalid type" } > | 1 > Error: Invalid type in arithmetic operation at (1) to: > 9 | x = (1.0, 2.0) * [complex :: +'1'] ! { dg-error "Invalid type" } > | 1 > Error: Operand of unary numeric operator ‘+’ at (1) is UNKNOWN or from: > 29 | print *, 2 * [real :: 0, 1+'1'] ! { dg-error "Invalid type" } > | 1 > Error: Invalid type in arithmetic operation at (1) to: > 29 | print *, 2 * [real :: 0, 1+'1'] ! { dg-error "Invalid type" } > | 1 > Error: Operands of binary numeric operator ‘+’ at (1) are INTEGER(4)/CHARACTER(1) Unfortunately, it doesn't fix the bogus incommensurate arrays errors.