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 A82433858C54 for ; Tue, 22 Nov 2022 11:53:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A82433858C54 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] ([2.10.193.163]) by smtp.orange.fr with ESMTPA id xRpZo1kEEY4XVxRppo78bG; Tue, 22 Nov 2022 12:53:06 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Tue, 22 Nov 2022 12:53:06 +0100 X-ME-IP: 2.10.193.163 Message-ID: <5039e120-a46a-f615-2eee-301fc1fd12f3@orange.fr> Date: Tue, 22 Nov 2022 12:52:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Subject: Re: [PATCH 1/2] Fortran: Cleanup struct ext_attr_t To: Bernhard Reutner-Fischer Cc: gcc-patches@gcc.gnu.org, Bernhard Reutner-Fischer , gfortran ML References: <20221110102031.1366016-1-aldot@gcc.gnu.org> <20221110102031.1366016-2-aldot@gcc.gnu.org> <20221121213410.79ae5601@nbbrfq> Content-Language: en-US From: Mikael Morin In-Reply-To: <20221121213410.79ae5601@nbbrfq> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.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=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 21/11/2022 à 21:34, Bernhard Reutner-Fischer a écrit : > On Mon, 21 Nov 2022 12:08:20 +0100 > Mikael Morin wrote: > >>> * gfortran.h (struct ext_attr_t): Remove middle_end_name. >>> * trans-decl.cc (add_attributes_to_decl): Move building >>> tree_list to ... >>> * decl.cc (gfc_match_gcc_attributes): ... here. Add the attribute to >>> the tree_list for the middle end. >>> >> I prefer to not do any middle-end stuff at parsing time, so I would >> rather not do this change. >> Not OK. > > Ok, that means we should filter-out those bits that we don't want to > write to the module (right?). We've plenty of bits left, more than Dave > Love would want to have added, i hope, so that should not be much of a > concern. > I didn't think of modules. Yes, that means we have to store (in memory) the attribute we have parsed, and we can filter-out the attributes at the time the attributes are written to the module. I don't think it is strictly necessary (for flatten, at least) though. > What that table really wants to say is whether or not this attribute > should be passed to the ME. Would it be acceptable to remove these > duplicate strings and just have a bool/char/int that is true if it > should be lowered (in trans-decl, as before)? But now i admit it's just > bikeshedding and we can as well leave it alone for now.. It was just a > though. > Yes, that would be acceptable.