From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-18.smtpout.orange.fr [80.12.242.18]) by sourceware.org (Postfix) with ESMTPS id 3776B3858D28 for ; Tue, 20 Sep 2022 09:28:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3776B3858D28 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 aZYSoj2Xotk1aaZYSoOr9b; Tue, 20 Sep 2022 11:28:38 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Tue, 20 Sep 2022 11:28:38 +0200 X-ME-IP: 86.215.174.255 Message-ID: <87c697b6-bc0a-0424-473d-9b64ecade073@orange.fr> Date: Tue, 20 Sep 2022 11:28:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: Proxy ping [PATCH] Fortran: Fix function attributes [PR100132] Content-Language: 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=-5.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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 List-Id: Hello, Le 19/09/2022 à 22:17, Harald Anlauf via Fortran a écrit : > Dear all, > > the following patch was submitted by Jose but never reviewed: > > https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html > > Before, we didn't set function attributes properly when > passing polymorphic pointers, which could lead to > mis-optimization. > > The patch is technically fine and regtests ok, although it > can be shortened slightly, which makes it more readable, > see attached. > > When testing the suggested testcase I found that it was > accepted (and working fine) with NAG, but it was rejected > by both Intel and Cray. This troubled me, but I think > it is standard conforming (F2018:15.5.2.7), while the > error messages issued by Intel > > PR100132.f90(61): error #8300: If a dummy argument is allocatable or a pointer, and the dummy or its associated actual argument is polymorphic, both dummy and actual must be polymorphic with the same declared type or both must be unlimited polymorphic. [S] > call set(s) > -------------^ > > and a similar one by Cray, suggest that they refer to > F2018:15.5.2.5, which IMHO does not apply here. > (The text in the error message seems very related to > the reasoning in Note 1 of that subsection). > > I'd like to hear (read: read) a second opinion on that. > I think you are correct. If the dummy wasn't INTENT(IN) the actual argument would have to be a pointer, and then 15.5.2.5 would apply, but it's not the case here. With INTENT(IN) the reasons for the constraints from Note 1 don't apply. I think you can go ahead.