From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-19.smtpout.orange.fr [80.12.242.19]) by sourceware.org (Postfix) with ESMTPS id BEA753858D26 for ; Sun, 30 Oct 2022 19:23:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org BEA753858D26 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 pDu3osuhanj75pDu9oW4SD; Sun, 30 Oct 2022 20:23:34 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Sun, 30 Oct 2022 20:23:34 +0100 X-ME-IP: 86.215.174.255 Message-ID: <7d8ddf07-e66d-2678-de99-0e575c70ea17@orange.fr> Date: Sun, 30 Oct 2022 20:23:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH] Fortran: ordering of hidden procedure arguments [PR107441] To: Harald Anlauf , fortran , gcc-patches References: Content-Language: fr, en-US From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 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_H2,SPF_HELO_PASS,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 List-Id: Le 28/10/2022 à 22:12, Harald Anlauf via Fortran a écrit : > Dear all, > > the passing of procedure arguments in Fortran sometimes requires > ancillary parameters that are "hidden". Examples are string length > and the presence status of scalar variables with optional+value > attribute. > > The gfortran ABI is actually documented: > > https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html > > The reporter found that there was a discrepancy between the > caller and the callee. This is corrected by the attached patch. > Hello, I think some discrepancy remains, as gfc_conv_procedure_call accumulates coarray stuff into the stringargs, while your change accumulates the associated parameter decls separately into hidden_arglist. It's not completely clear to me whether it is really problematic (string length and coarray metadata are both integers anyway), but I suspect it is. Another probable issue is your change to create_function_arglist changes arglist/hidden_arglist without also changing typelist/hidden_typelist accordingly. I think a change to gfc_get_function_type is also necessary: as the function decl is changed, the decl type need to be changed as well. I will see whether I can manage to exhibit testcases for these issues.