From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp-23.smtpout.orange.fr [80.12.242.23]) by sourceware.org (Postfix) with ESMTPS id 54F873858C1F for ; Tue, 22 Nov 2022 13:17:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 54F873858C1F 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 xT9codNazm0FgxT9cofbUs; Tue, 22 Nov 2022 14:17:37 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Tue, 22 Nov 2022 14:17:37 +0100 X-ME-IP: 2.10.193.163 Message-ID: <2ab6c3f9-22e4-1e57-31fc-4d34cf43a957@orange.fr> Date: Tue, 22 Nov 2022 14:17:36 +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 2/2] Fortran: add attribute target_clones Content-Language: fr, en-US To: Bernhard Reutner-Fischer Cc: gcc-patches@gcc.gnu.org, Bernhard Reutner-Fischer , gfortran ML References: <20221109190225.96037-1-aldot@gcc.gnu.org> <20221109190225.96037-3-aldot@gcc.gnu.org> <20221121232613.66c79474@nbbrfq> From: Mikael Morin In-Reply-To: <20221121232613.66c79474@nbbrfq> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 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 21/11/2022 à 23:26, Bernhard Reutner-Fischer a écrit : > On Mon, 21 Nov 2022 20:13:40 +0100 > Mikael Morin wrote: > >> Hello, >> >> Le 09/11/2022 à 20:02, Bernhard Reutner-Fischer via Fortran a écrit : >>> Hi! >>> (...) >>> + if (allow_multiple && gfc_match_char (')') != MATCH_YES) >>> + { >>> + gfc_error ("expected ')' at %C"); >>> + return NULL_TREE; >>> + } >>> + >>> + return attr_args; >>> +} >> I'm not sure this function need to do all the parsing manually. >> I would rather use gfc_match_actual_arglist, or maybe implement the >> function as a wrapper around it. >> What is allowed here? Are non-literal constants allowed, for example >> parameter variables? Is line continuation supported ? > > Line continuation is supported i think. > Parameter variables supposedly are or should not be supported. Why would > you do that in the context of an attribute target decl? > Either way, if the ME does not find such an fndecl, it will complain > and ignore the attribute. > I don't understand non-literal constants in this context. > This very attribute applies to decls, so the existing code supposedly > matches a comma separated list of identifiers. The usual dollar-ok > caveats apply. > No, my comment and my questions were about your function, which, as I understand it, matches the arguments to the attribute: it matches open and closing parenthesis, double quotes, etc. Matching of decl names comes after that. I asked the question about non-literal constant (and the other as well), because I saw it as a possible reason to not reuse the existing parsing functions. > As to gfc_match_actual_arglist, probably. > target_clones has > + { "target_clones", 1, -1, true, false, false, false, > + dummy, NULL }, > with tree-core.h struct attribute_spec, so > name, min=1, max=unbounded, decl_required=yes, ...ignore... > > hence applies to functions and subroutines and the like. It does take an > unbounded list of strings, isa1, isa2, isa4, default. We could add > "default" unless seen, but i'd rather want it spelled out by the user > for the user is supposed to know what she's doing, as in c or c++. > The ME has code to sanity-check the attributes, including conflicting > (ME) attributes. > > The reason why i contemplated with a separate parser was that for stuff > like regparm or sseregparm, you would want to require a single number > for the equivalent of > > __attribute__((regparm(3),stdcall) > > which you would provide in 2 separate !GCC$ attributes i assume. > Well, the check could as easily be enforced after parsing with the existing parsing functions. >> >> Nothing (bad) to say about the rest, but there is enough to change with >> the above comments. > > Yes, many thanks for your comments. > I think there is no other non-intrusive way to pass the data through the > frontend. So for an acceptable way this means touching quite some spots > for every single ME attribute anybody would like to add in the future. I'm not sure I understand. Please let's just add what is necessary for this attribute, not more.