From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-21.smtpout.orange.fr [80.12.242.21]) by sourceware.org (Postfix) with ESMTPS id C0CDD3858C2D for ; Thu, 3 Nov 2022 10:06:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0CDD3858C2D 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] ([83.197.245.49]) by smtp.orange.fr with ESMTPA id qX7So1bAoKOP1qX7Yo8SLm; Thu, 03 Nov 2022 11:06:51 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Thu, 03 Nov 2022 11:06:51 +0100 X-ME-IP: 83.197.245.49 Message-ID: <91afe6ef-e5f4-d3d8-ad15-3271fd4e61cd@orange.fr> Date: Thu, 3 Nov 2022 11:06:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.0 Subject: Re: [PATCH, v2] Fortran: ordering of hidden procedure arguments [PR107441] To: Harald Anlauf , fortran@gcc.gnu.org Cc: gcc-patches@gcc.gnu.org References: <7d8ddf07-e66d-2678-de99-0e575c70ea17@orange.fr> <327319ac-4ef9-1e48-e993-57113d802d3b@orange.fr> <85a5951a-7ea4-57b3-895a-ff7dbf1ef92e@orange.fr> <93a5f029-4411-3424-f6ee-3b2bcf210050@gmx.de> <8725411a-979b-dd53-d1fe-5b041482a8eb@gmx.de> Content-Language: en-US From: Mikael Morin In-Reply-To: <8725411a-979b-dd53-d1fe-5b041482a8eb@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,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 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit : > Am 02.11.22 um 18:20 schrieb Mikael Morin: >> Unfortunately no, the coarray case works, but the other problem remains. >> The type problem is not visible in the definition of S, it is in the >> declaration of S's prototype in P. >> >> S is defined as: >> >> void s (character(kind=1)[1:_c] & restrict c, integer(kind=4) o, >> logical(kind=1) _o, integer(kind=8) _c) >> { >> ... >> } >> >> but P has: >> >> void p () >> { >>    static void s (character(kind=1)[1:] & restrict, integer(kind=4), >> integer(kind=8), logical(kind=1)); >>    void (*) (character(kind=1)[1:] & restrict, integer(kind=4), >> integer(kind=8), logical(kind=1)) pp; >> >>    pp = s; >> ... >> } > > Right, now I see it too.  Simplified case: > > program p >   call s ("abcd") > contains >   subroutine s(c, o) >     character(*) :: c >     integer, optional, value :: o >   end subroutine s > end > > I do see what needs to be done in gfc_get_function_type, which seems > in fact very simple.  But I get really lost in create_function_arglist > when trying to get the typelist right. > > One thing is I really don't understand how the (hidden_)typelist is > managed here.  How does that macro TREE_CHAIN work?  Can we somehow > chain two typelists the same way we chain arguments? > TREE_CHAIN is just a linked list "next" pointer like there is in the fortran frontend a "next" pointer in gfc_ref or gfc_actual_arglist structures. Yes, we can chain typelists; the implementation of chainon in tree.cc is just TREE_CHAIN appending under the hood. > (Failing that, I tried to split the loop over the dummy arguments in > create_function_arglist into two passes, one for the optional+value > variant, and one for the rest.  It turned out to be a bad idea...) > Not necessarily a bad idea, but one has to be careful to keep linked lists synchronized with argument walking. The most simple, I think, is to move the hidden_typelist advancement for optional, value presence arguments from the main loop to a preliminary loop. I hope it helps.