Le 21/11/2022 à 23:26, Bernhard Reutner-Fischer a écrit :
On Mon, 21 Nov 2022 20:13:40 +0100
Mikael Morin <morin-mik...@orange.fr> 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.
