* [PATCH 0/2] Fortran: Add attribute flatten
@ 2022-11-10 10:20 Bernhard Reutner-Fischer
2022-11-10 10:20 ` [PATCH 1/2] Fortran: Cleanup struct ext_attr_t Bernhard Reutner-Fischer
2022-11-10 10:20 ` [PATCH 2/2] Fortran: Add attribute flatten Bernhard Reutner-Fischer
0 siblings, 2 replies; 8+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-11-10 10:20 UTC (permalink / raw)
To: gcc-patches
Cc: Bernhard Reutner-Fischer, Bernhard Reutner-Fischer, gfortran ML
Hi!
I could imagine that the flatten attribute might be useful.
Do we want to add support for it for gcc-13?
Bernhard Reutner-Fischer (2):
Fortran: Cleanup struct ext_attr_t
Fortran: Add attribute flatten
gcc/fortran/decl.cc | 41 +++++++++++++-------
gcc/fortran/f95-lang.cc | 2 +
gcc/fortran/gfortran.h | 1 -
gcc/fortran/gfortran.texi | 8 ++++
gcc/fortran/trans-decl.cc | 13 +------
gcc/testsuite/gfortran.dg/attr_flatten-1.f90 | 41 ++++++++++++++++++++
6 files changed, 80 insertions(+), 26 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/attr_flatten-1.f90
--
2.38.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 1/2] Fortran: Cleanup struct ext_attr_t
2022-11-10 10:20 [PATCH 0/2] Fortran: Add attribute flatten Bernhard Reutner-Fischer
@ 2022-11-10 10:20 ` Bernhard Reutner-Fischer
2022-11-21 11:08 ` Mikael Morin
2022-11-10 10:20 ` [PATCH 2/2] Fortran: Add attribute flatten Bernhard Reutner-Fischer
1 sibling, 1 reply; 8+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-11-10 10:20 UTC (permalink / raw)
To: gcc-patches
Cc: Bernhard Reutner-Fischer, Bernhard Reutner-Fischer, gfortran ML
Tiny cleanup opportunity since we now have ext_attr_args in
struct symbol_attribute.
Bootstrapped and regtested on x86_64-unknown-linux with no new
regressions.
Ok for trunk if the prerequisite was approved ([PATCH 2/2] Fortran: add
attribute target_clones) ?
gcc/fortran/ChangeLog:
* 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.
Cc: gfortran ML <fortran@gcc.gnu.org>
---
gcc/fortran/decl.cc | 35 +++++++++++++++++++++++------------
gcc/fortran/gfortran.h | 1 -
gcc/fortran/trans-decl.cc | 13 +------------
3 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 3a619dbdd34..d312d4812b6 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -11802,15 +11802,15 @@ gfc_match_gcc_attribute_args (bool require_string, bool allow_multiple)
}
const ext_attr_t ext_attr_list[] = {
- { "dllimport", EXT_ATTR_DLLIMPORT, "dllimport" },
- { "dllexport", EXT_ATTR_DLLEXPORT, "dllexport" },
- { "cdecl", EXT_ATTR_CDECL, "cdecl" },
- { "stdcall", EXT_ATTR_STDCALL, "stdcall" },
- { "fastcall", EXT_ATTR_FASTCALL, "fastcall" },
- { "no_arg_check", EXT_ATTR_NO_ARG_CHECK, NULL },
- { "deprecated", EXT_ATTR_DEPRECATED, NULL },
- { "target_clones",EXT_ATTR_TARGET_CLONES,NULL },
- { NULL, EXT_ATTR_LAST, NULL }
+ { "dllimport", EXT_ATTR_DLLIMPORT },
+ { "dllexport", EXT_ATTR_DLLEXPORT },
+ { "cdecl", EXT_ATTR_CDECL },
+ { "stdcall", EXT_ATTR_STDCALL },
+ { "fastcall", EXT_ATTR_FASTCALL, },
+ { "no_arg_check", EXT_ATTR_NO_ARG_CHECK },
+ { "deprecated", EXT_ATTR_DEPRECATED },
+ { "target_clones",EXT_ATTR_TARGET_CLONES },
+ { NULL, EXT_ATTR_LAST }
};
/* Match a !GCC$ ATTRIBUTES statement of the form:
@@ -11854,6 +11854,20 @@ gfc_match_gcc_attributes (void)
gfc_error ("Unknown attribute in !GCC$ ATTRIBUTES statement at %C");
return MATCH_ERROR;
}
+
+ /* Check for errors.
+ If everything is fine, add attributes the middle-end has to know about.
+ */
+ if (!gfc_add_ext_attribute (&attr, (ext_attr_id_t)id, &gfc_current_locus))
+ return MATCH_ERROR;
+ else if (id == EXT_ATTR_DLLIMPORT
+ || id == EXT_ATTR_DLLEXPORT
+ || id == EXT_ATTR_CDECL
+ || id == EXT_ATTR_STDCALL
+ || id == EXT_ATTR_FASTCALL)
+ attr.ext_attr_args
+ = chainon (attr.ext_attr_args,
+ build_tree_list (get_identifier (name), NULL_TREE));
else if (id == EXT_ATTR_TARGET_CLONES)
{
attr_args
@@ -11864,9 +11878,6 @@ gfc_match_gcc_attributes (void)
build_tree_list (get_identifier (name), attr_args));
}
- if (!gfc_add_ext_attribute (&attr, (ext_attr_id_t)id, &gfc_current_locus))
- return MATCH_ERROR;
-
gfc_gobble_whitespace ();
ch = gfc_next_ascii_char ();
if (ch == ':')
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index ce0cb61e647..c4deec0d5b8 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -847,7 +847,6 @@ typedef struct
{
const char *name;
unsigned id;
- const char *middle_end_name;
}
ext_attr_t;
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index 24cbd4cda28..7d5d2bdbb37 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -1436,18 +1436,7 @@ gfc_add_assign_aux_vars (gfc_symbol * sym)
static tree
add_attributes_to_decl (symbol_attribute sym_attr, tree list)
{
- unsigned id;
- tree attr;
-
- for (id = 0; id < EXT_ATTR_NUM; id++)
- if (sym_attr.ext_attr & (1 << id) && ext_attr_list[id].middle_end_name)
- {
- attr = build_tree_list (
- get_identifier (ext_attr_list[id].middle_end_name),
- NULL_TREE);
- list = chainon (list, attr);
- }
- /* Add attribute args. */
+ /* Add attributes and their arguments. */
if (sym_attr.ext_attr_args != NULL_TREE)
list = chainon (list, sym_attr.ext_attr_args);
--
2.38.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 2/2] Fortran: Add attribute flatten
2022-11-10 10:20 [PATCH 0/2] Fortran: Add attribute flatten Bernhard Reutner-Fischer
2022-11-10 10:20 ` [PATCH 1/2] Fortran: Cleanup struct ext_attr_t Bernhard Reutner-Fischer
@ 2022-11-10 10:20 ` Bernhard Reutner-Fischer
2022-11-21 11:24 ` Mikael Morin
1 sibling, 1 reply; 8+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-11-10 10:20 UTC (permalink / raw)
To: gcc-patches
Cc: Bernhard Reutner-Fischer, Bernhard Reutner-Fischer, gfortran ML
Bootstrapped and regtested cleanly on x86_unknown-linux.
The document bits will be rewritten for rst.
Ok for trunk if the prerequisite target_clones patch is approved?
gcc/fortran/ChangeLog:
* decl.cc (gfc_match_gcc_attributes): Handle flatten.
* f95-lang.cc (gfc_attribute_table): Add flatten.
* gfortran.texi: Document attribute flatten.
gcc/testsuite/ChangeLog:
* gfortran.dg/attr_flatten-1.f90: New test.
---
gcc/fortran/decl.cc | 8 +++-
gcc/fortran/f95-lang.cc | 2 +
gcc/fortran/gfortran.texi | 8 ++++
gcc/testsuite/gfortran.dg/attr_flatten-1.f90 | 41 ++++++++++++++++++++
4 files changed, 57 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/attr_flatten-1.f90
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index d312d4812b6..3d210c26eb5 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -11841,6 +11841,7 @@ gfc_match_gcc_attributes (void)
for(;;)
{
char ch;
+ bool known_attr0args = false;
if (gfc_match_name (name) != MATCH_YES)
return MATCH_ERROR;
@@ -11849,7 +11850,9 @@ gfc_match_gcc_attributes (void)
if (strcmp (name, ext_attr_list[id].name) == 0)
break;
- if (id == EXT_ATTR_LAST)
+ if (strcmp (name, "flatten") == 0)
+ known_attr0args = true; /* Handled below. We do not need a bit. */
+ else if (id == EXT_ATTR_LAST)
{
gfc_error ("Unknown attribute in !GCC$ ATTRIBUTES statement at %C");
return MATCH_ERROR;
@@ -11864,7 +11867,8 @@ gfc_match_gcc_attributes (void)
|| id == EXT_ATTR_DLLEXPORT
|| id == EXT_ATTR_CDECL
|| id == EXT_ATTR_STDCALL
- || id == EXT_ATTR_FASTCALL)
+ || id == EXT_ATTR_FASTCALL
+ || known_attr0args)
attr.ext_attr_args
= chainon (attr.ext_attr_args,
build_tree_list (get_identifier (name), NULL_TREE));
diff --git a/gcc/fortran/f95-lang.cc b/gcc/fortran/f95-lang.cc
index 7154568aec5..ddb5b686cf6 100644
--- a/gcc/fortran/f95-lang.cc
+++ b/gcc/fortran/f95-lang.cc
@@ -101,6 +101,8 @@ static const struct attribute_spec gfc_attribute_table[] =
gfc_handle_omp_declare_target_attribute, NULL },
{ "target_clones", 1, -1, true, false, false, false,
gfc_handle_omp_declare_target_attribute, NULL },
+ { "flatten", 0, 0, true, false, false, false,
+ gfc_handle_omp_declare_target_attribute, NULL },
{ NULL, 0, 0, false, false, false, false, NULL, NULL }
};
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index 06e4c8c00a1..be650f28b62 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -3280,6 +3280,14 @@ contains
end module mymod
@end smallexample
+@node flatten
+
+Procedures annotated with the @code{flatten} attribute have their
+callees inlined, if possible.
+Please refer to
+@ref{Top,,Common Function Attributes,gcc,Using the GNU Compiler Collection (GCC)}
+for details about the respective attribute.
+
The attributes are specified using the syntax
@code{!GCC$ ATTRIBUTES} @var{attribute-list} @code{::} @var{variable-list}
diff --git a/gcc/testsuite/gfortran.dg/attr_flatten-1.f90 b/gcc/testsuite/gfortran.dg/attr_flatten-1.f90
new file mode 100644
index 00000000000..0b72f1ba17c
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/attr_flatten-1.f90
@@ -0,0 +1,41 @@
+! { dg-do compile }
+! { dg-additional-options "-fdump-tree-optimized" }
+! Test __attribute__((flatten))
+!
+module attr_flttn_1_a
+ implicit none
+contains
+ subroutine sub1(i)
+ integer, intent(in) :: i
+ integer :: n
+ do n = 1, i
+ print *, "marker1 ", i, i+n;
+ enddo
+ end
+ subroutine sub2(i)
+ integer, intent(in) :: i
+ integer :: n
+ do n = 1, i
+ print *, "marker2 ", i, i*i-n;
+ enddo
+ end
+end module
+module attr_flttn_1_b
+ use attr_flttn_1_a
+contains
+ subroutine sub3
+!GCC$ ATTRIBUTES flatten :: sub3
+ print *, "marker3 "
+ call sub2(4711)
+ call sub1(42)
+ end
+end module
+! Without the attribute flatten we would have 1 character write for each marker.
+! That would be 3 _gfortran_transfer_character_write.*marker
+! With the attribute, we have one for each sub plus marker1 and marker2
+! which were inlined into sub3.
+! So this gives 5 _gfortran_transfer_character_write.*marker
+! and there should be no calls to sub1 (); nor sub2 ();
+! { dg-final { scan-tree-dump-times { _gfortran_transfer_character_write .*?marker} 5 "optimized" } }
+! { dg-final { scan-tree-dump-not { sub1 \([^\)][^\)]*\);} "optimized" } }
+! { dg-final { scan-tree-dump-not { sub2 \([^\)][^\)]*\);} "optimized" } }
--
2.38.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] Fortran: Cleanup struct ext_attr_t
2022-11-10 10:20 ` [PATCH 1/2] Fortran: Cleanup struct ext_attr_t Bernhard Reutner-Fischer
@ 2022-11-21 11:08 ` Mikael Morin
2022-11-21 20:34 ` Bernhard Reutner-Fischer
0 siblings, 1 reply; 8+ messages in thread
From: Mikael Morin @ 2022-11-21 11:08 UTC (permalink / raw)
To: Bernhard Reutner-Fischer, gcc-patches
Cc: Bernhard Reutner-Fischer, gfortran ML
Hello,
Le 10/11/2022 à 11:20, Bernhard Reutner-Fischer via Fortran a écrit :
> Tiny cleanup opportunity since we now have ext_attr_args in
> struct symbol_attribute.
> Bootstrapped and regtested on x86_64-unknown-linux with no new
> regressions.
> Ok for trunk if the prerequisite was approved ([PATCH 2/2] Fortran: add
> attribute target_clones) ?
>
> gcc/fortran/ChangeLog:
>
> * 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] Fortran: Add attribute flatten
2022-11-10 10:20 ` [PATCH 2/2] Fortran: Add attribute flatten Bernhard Reutner-Fischer
@ 2022-11-21 11:24 ` Mikael Morin
2022-11-21 20:13 ` Bernhard Reutner-Fischer
0 siblings, 1 reply; 8+ messages in thread
From: Mikael Morin @ 2022-11-21 11:24 UTC (permalink / raw)
To: Bernhard Reutner-Fischer, gcc-patches
Cc: Bernhard Reutner-Fischer, gfortran ML
Le 10/11/2022 à 11:20, Bernhard Reutner-Fischer via Fortran a écrit :
> Bootstrapped and regtested cleanly on x86_unknown-linux.
> The document bits will be rewritten for rst.
> Ok for trunk if the prerequisite target_clones patch is approved?
>
> gcc/fortran/ChangeLog:
>
> * decl.cc (gfc_match_gcc_attributes): Handle flatten.
> * f95-lang.cc (gfc_attribute_table): Add flatten.
> * gfortran.texi: Document attribute flatten.
>
> gcc/testsuite/ChangeLog:
>
> * gfortran.dg/attr_flatten-1.f90: New test.
> ---
> gcc/fortran/decl.cc | 8 +++-
> gcc/fortran/f95-lang.cc | 2 +
> gcc/fortran/gfortran.texi | 8 ++++
> gcc/testsuite/gfortran.dg/attr_flatten-1.f90 | 41 ++++++++++++++++++++
> 4 files changed, 57 insertions(+), 2 deletions(-)
> create mode 100644 gcc/testsuite/gfortran.dg/attr_flatten-1.f90
>
> diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
> index d312d4812b6..3d210c26eb5 100644
> --- a/gcc/fortran/decl.cc
> +++ b/gcc/fortran/decl.cc
(...)
> @@ -11849,7 +11850,9 @@ gfc_match_gcc_attributes (void)
> if (strcmp (name, ext_attr_list[id].name) == 0)
> break;
>
> - if (id == EXT_ATTR_LAST)
> + if (strcmp (name, "flatten") == 0)
> + known_attr0args = true; /* Handled below. We do not need a bit. */
I don't see the point to have all the attributes needing a bit except
one that doesn't but needs a specific handling.
What does it look like without the 1/2 patch and if one bit is also used
for flatten, like the other attributes?
> + else if (id == EXT_ATTR_LAST)
> {
> gfc_error ("Unknown attribute in !GCC$ ATTRIBUTES statement at %C");
> return MATCH_ERROR;
> diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
> index 06e4c8c00a1..be650f28b62 100644
> --- a/gcc/fortran/gfortran.texi
> +++ b/gcc/fortran/gfortran.texi
> @@ -3280,6 +3280,14 @@ contains
> end module mymod
> @end smallexample
>
> +@node flatten
> +
> +Procedures annotated with the @code{flatten} attribute have their
> +callees inlined, if possible.
I'm not a native speaker, but I find this sentence confusing.
The words of the gcc manual you are refering to seem more clear: "every
call inside the function is inlined, if possible".
> +Please refer to
> +@ref{Top,,Common Function Attributes,gcc,Using the GNU Compiler Collection (GCC)}
> +for details about the respective attribute.
> +
> The attributes are specified using the syntax
>
> @code{!GCC$ ATTRIBUTES} @var{attribute-list} @code{::} @var{variable-list}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 2/2] Fortran: Add attribute flatten
2022-11-21 11:24 ` Mikael Morin
@ 2022-11-21 20:13 ` Bernhard Reutner-Fischer
0 siblings, 0 replies; 8+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-11-21 20:13 UTC (permalink / raw)
To: Mikael Morin
Cc: rep.dot.nop, gcc-patches, Bernhard Reutner-Fischer, gfortran ML
On Mon, 21 Nov 2022 12:24:11 +0100
Mikael Morin <morin-mikael@orange.fr> wrote:
> > --- a/gcc/fortran/decl.cc
> > +++ b/gcc/fortran/decl.cc
> (...)
> > @@ -11849,7 +11850,9 @@ gfc_match_gcc_attributes (void)
> > if (strcmp (name, ext_attr_list[id].name) == 0)
> > break;
> >
> > - if (id == EXT_ATTR_LAST)
> > + if (strcmp (name, "flatten") == 0)
> > + known_attr0args = true; /* Handled below. We do not need a bit. */
>
> I don't see the point to have all the attributes needing a bit except
> one that doesn't but needs a specific handling.
> What does it look like without the 1/2 patch and if one bit is also used
> for flatten, like the other attributes?
I've changed target_clones not to use a bit locally because it's not
needed. From my understanding, we only need the bits for attributes
that change the calling convention or the caller(at least so far, but
that does make sense to me). Remember that we store these bits in the
module. Presumably because we have to make sure that a program/module
uses the correct calling convention for a module function annotated
with such an attribute (think cdecl, stdcall, fastcall, dllimport,
dllexport, or the non-implemented regparm, sseregparm) or for
attributes that otherwise influence the callers or callees (like
deprecated or no_arg_check).
Attributes like target_clones or flatten or (probably) optimize etc, do
not influence the callees, so we really do not need to store them in
the module.
Can you think of a reason to store them nevertheless?
> > + else if (id == EXT_ATTR_LAST)
> > {
> > gfc_error ("Unknown attribute in !GCC$ ATTRIBUTES statement at %C");
> > return MATCH_ERROR;
>
> > diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
> > index 06e4c8c00a1..be650f28b62 100644
> > --- a/gcc/fortran/gfortran.texi
> > +++ b/gcc/fortran/gfortran.texi
> > @@ -3280,6 +3280,14 @@ contains
> > end module mymod
> > @end smallexample
> >
> > +@node flatten
> > +
> > +Procedures annotated with the @code{flatten} attribute have their
> > +callees inlined, if possible.
> I'm not a native speaker, but I find this sentence confusing.
> The words of the gcc manual you are refering to seem more clear: "every
> call inside the function is inlined, if possible".
Me neither and it was a bit too brief. I've changed this to:
Every call inside a procedure annotated with the @code{flatten} attribute
is inlined, if possible. Please refer to
@ref{Top,,Common Function Attributes,gcc,Using the GNU Compiler Collection (GCC>
for details about the respective attribute.
Is that better?
That said, i think this whole attribute section in the manual is not
structured too well. I'd prefer to have a list of attributes like in the
"Common Function Attributes" section in the extend.texi.
Maybe it would be better to just start a new list of attributes at the
end of the current @subsection ATTRIBUTES directive, a subsubsection
with "Other attributes" and just itemize the new ones? We'd point
people to the Top docs once for further details and then just briefly
list the attributes we support. Would that be acceptable?
Many thanks for your comments!
>
> > +Please refer to
> > +@ref{Top,,Common Function Attributes,gcc,Using the GNU Compiler Collection (GCC)}
> > +for details about the respective attribute.
> > +
> > The attributes are specified using the syntax
> >
> > @code{!GCC$ ATTRIBUTES} @var{attribute-list} @code{::} @var{variable-list}
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] Fortran: Cleanup struct ext_attr_t
2022-11-21 11:08 ` Mikael Morin
@ 2022-11-21 20:34 ` Bernhard Reutner-Fischer
2022-11-22 11:52 ` Mikael Morin
0 siblings, 1 reply; 8+ messages in thread
From: Bernhard Reutner-Fischer @ 2022-11-21 20:34 UTC (permalink / raw)
To: Mikael Morin
Cc: rep.dot.nop, gcc-patches, Bernhard Reutner-Fischer, gfortran ML
On Mon, 21 Nov 2022 12:08:20 +0100
Mikael Morin <morin-mikael@orange.fr> 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.
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.
thanks,
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 1/2] Fortran: Cleanup struct ext_attr_t
2022-11-21 20:34 ` Bernhard Reutner-Fischer
@ 2022-11-22 11:52 ` Mikael Morin
0 siblings, 0 replies; 8+ messages in thread
From: Mikael Morin @ 2022-11-22 11:52 UTC (permalink / raw)
To: Bernhard Reutner-Fischer
Cc: gcc-patches, Bernhard Reutner-Fischer, gfortran ML
Le 21/11/2022 à 21:34, Bernhard Reutner-Fischer a écrit :
> On Mon, 21 Nov 2022 12:08:20 +0100
> Mikael Morin <morin-mikael@orange.fr> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-11-22 11:53 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-10 10:20 [PATCH 0/2] Fortran: Add attribute flatten Bernhard Reutner-Fischer
2022-11-10 10:20 ` [PATCH 1/2] Fortran: Cleanup struct ext_attr_t Bernhard Reutner-Fischer
2022-11-21 11:08 ` Mikael Morin
2022-11-21 20:34 ` Bernhard Reutner-Fischer
2022-11-22 11:52 ` Mikael Morin
2022-11-10 10:20 ` [PATCH 2/2] Fortran: Add attribute flatten Bernhard Reutner-Fischer
2022-11-21 11:24 ` Mikael Morin
2022-11-21 20:13 ` Bernhard Reutner-Fischer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).