From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-13.smtpout.orange.fr [80.12.242.13]) by sourceware.org (Postfix) with ESMTPS id 3E67038582A7 for ; Fri, 4 Nov 2022 09:54:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3E67038582A7 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 qtOfoAeDjBDYDqtOlosCG8; Fri, 04 Nov 2022 10:54:05 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Fri, 04 Nov 2022 10:54:05 +0100 X-ME-IP: 83.197.245.49 Message-ID: <3ca46ea0-ee6a-cbc6-d3af-99b8db698307@orange.fr> Date: Fri, 4 Nov 2022 10:53:57 +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> <91afe6ef-e5f4-d3d8-ad15-3271fd4e61cd@orange.fr> Content-Language: 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=-3.0 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=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 03/11/2022 à 23:03, Harald Anlauf a écrit : > Am 03.11.22 um 11:06 schrieb Mikael Morin: >> Le 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit : >>> 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. >> > > I've spent some time not only staring at create_function_arglist, > but trying several variations handling the declared hidden parms, > and applying the necessary adjustments to gfc_get_function_type. > (Managing linked trees is not the issue, just understanding them.) > I've been unable to get the declarations in sync, and would need > help how to debug the mess I've created.  Dropping my patch for > the time being. > If you want, we can meet on IRC somewhen (tonight?).