From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-14.smtpout.orange.fr [80.12.242.14]) by sourceware.org (Postfix) with ESMTPS id 43618394908A for ; Thu, 6 Oct 2022 20:14:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 43618394908A 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 gXGMoFTuABDYDgXGWoRSWc; Thu, 06 Oct 2022 22:14:45 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Thu, 06 Oct 2022 22:14:45 +0200 X-ME-IP: 86.215.174.255 Message-ID: <97dd508f-83b0-5ed0-8cb5-f4f7c8fe08e6@orange.fr> Date: Thu, 6 Oct 2022 22:14:34 +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, v2] Fortran: error recovery for invalid types in array constructors [PR107000] Content-Language: fr, en-US To: Harald Anlauf Cc: fortran , gcc-patches References: <1bf3b7b5-39ac-0c94-256c-f739a4746a7b@orange.fr> From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,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: Le 05/10/2022 à 23:40, Harald Anlauf a écrit : > >> There is one last thing that I'm dissatisfied with. >> The handling of unknown types should be moved to reduce_binary, because >> the dispatching in reduce_binary doesn't handle EXPR_OP, so even if >> either or both operands are scalar, they are handled by the (array vs >> array) reduce_binary_aa function. That's confusing. Thinking about it again, I'm not sure my suggestion is right here. > > Do you have an example? > No. Actually, I think it works, but a weird way. For example, for this case: [real :: 2] * [real :: +(.true.)] First there is a "root" invocation of reduce binary with arguments [real :: 2] and [real :: +(.true.)] The root invocation of reduce_binary will call reduce_binary_aa. This is normal. Then reduce_binary_aa calls reduce_binary again with arguments 2 and +(.true.). And reduce_binary calls again reduce_binary_aa with those arguments. This is weird, reduce_binary_aa is supposed to have arrays for both arguments. The same goes for the array vs constant case, reduce_binary_ca (or reduce_binary_ac) is invoked with two scalars, while if you look at reduce_binary, you would expect that we only get to reduce_binary_ca with a scalar constant and an array as arguments. I think the checks in the three reduce_binary_* functions should be moved into their respective loops, so that we detect the invalid type just before these weird recursive calls instead of just after entering into them. OK with that change.