Re: PR fortran/39627 [meta-bug] Fortran 2008 support
On 13.10.23 08:31, Richard Biener wrote: On Thu, Oct 12, 2023 at 6:54 PM Paul Richard Thomas wrote: I have posted the version 4 of Ian Chivers and Jane Sleightholme's F2008 compliance table as an attachment to PR39627. ... I am halfway through the F2018 table and will post it on PR85836 when I have done as much as I can. Btw, C++ hashttps://gcc.gnu.org/projects/cxx-status.html on the main web pages (though I needed to use google to find it, discoverability on our webpage isn't too great :/). Likewise albeit slightly differently for OpenMP, https://gcc.gnu.org/projects/gomp/#implementation-status I think we link the C++ page from time to time in release notes at gcc-*/changes.html. For Fortran, we also use the wiki – and I do note that we do have a F2018 page, but not yet a Fortran2023 one: https://gcc.gnu.org/wiki/Fortran2003Status https://gcc.gnu.org/wiki/Fortran2008Status https://gcc.gnu.org/wiki/Fortran2018Status Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: PR fortran/39627 [meta-bug] Fortran 2008 support
Hi Richard, I take the non-compliances to be bugs and so I think that there is value in posting the table on the meta-bug PR. Once the table is on its way to be published, I will replace it on the PR with a table containing the partial- and non-compliances only or raise specific PRs. For the F2018 compliance, the situation is rather more difficult since gfortran's coverage is so patchy. Thus far it has taken a lot of work to produce something even halfway accurate. I would baulk at writing PRs for all the 'P's and 'N's and so it will have to a table for that. The gfortran wiki has https://gcc.gnu.org/wiki/Fortran2008Status and https://gcc.gnu.org/wiki/Fortran2018Status. I will update these pages once I am entirely sure of the state of each. Cheers Paul On Fri, 13 Oct 2023 at 07:32, Richard Biener wrote: > On Thu, Oct 12, 2023 at 6:54 PM Paul Richard Thomas > wrote: > > > > I have posted the version 4 of Ian Chivers and Jane Sleightholme's F2008 > compliance table as an attachment to PR39627. > > > > With Harald Anlauf's help it has been updated to correspond to gfortran > 13.2. In the previous return for gfortran, a number of lines had not been > filled out at all. This has now been done and a rather rough and ready > testcase providing the "evidence" for compliance or not has also been > posted on the PR. > > > > I would welcome comments/corrections if they are also posted on the PR. > > > > I am halfway through the F2018 table and will post it on PR85836 when I > have done as much as I can. I am out for a week and so this will most > likely happen at the end of October. Jerry DeLisle has helped out with > lines 3.x of this table. > > > > As well as being a reply to Ian and Jane, I hope that the tables and > testcases will serve as a resource for gfortran developers as a more > systematic supplement to the meta-bug dependences. > > Btw, C++ has https://gcc.gnu.org/projects/cxx-status.html on the main > web pages (though I needed to use google to find it, > discoverability on our webpage isn't too great :/). Maybe something > similar can be set up for Fortran > instead of relying on a bugreport? > > Richard. > > > Regards > > > > Paul > > >
Re: [Patch] Fortran: Support OpenMP's 'allocate' directive for stack vars
On Tue, Oct 10, 2023 at 06:46:35PM +0200, Tobias Burnus wrote:
> * parse.cc (check_omp_allocate_stmt): Permit procedure pointers
> here (rejected later) for less mislreading diagnostic.
s/misl/mis/
> libgomp/ChangeLog:
>
> * libgomp.texi:
Fill in something here.
> @@ -7220,8 +7227,7 @@ gfc_resolve_omp_allocate (gfc_namespace *ns,
> gfc_omp_namelist *list)
>&n->where);
> continue;
> }
> - if (ns != n->sym->ns || n->sym->attr.use_assoc
> - || n->sym->attr.host_assoc || n->sym->attr.imported)
> + if (ns != n->sym->ns || n->sym->attr.use_assoc ||
> n->sym->attr.imported)
s/ n/ n/
> --- a/gcc/gimplify.cc
> +++ b/gcc/gimplify.cc
> @@ -1400,23 +1400,53 @@ gimplify_bind_expr (tree *expr_p, gimple_seq *pre_p)
> "region must specify an % clause", t);
> /* Skip for omp_default_mem_alloc (= 1),
>unless align is present. */
> - else if (!errorcount
> -&& (align != NULL_TREE
> -|| alloc == NULL_TREE
> -|| !integer_onep (alloc)))
> + else if (errorcount
> +|| (align == NULL_TREE
> +&& alloc != NULL_TREE
> +&& integer_onep (alloc)))
> + DECL_ATTRIBUTES (t) = remove_attribute ("omp allocate",
> + DECL_ATTRIBUTES (t));
Probably already preexisting, by I wonder how safe remove_attribute is.
Aren't attributes shared in some cases
(like __attribute__((attr1, attr2, attr3)) int a, b, c, d;)?
Not really sure if something unshares them afterwards.
If they are shared, adding new attributes is fine, that will make the new
additions not shared and the tail shared, but remove_attribute could remove
it from all of them at once. Perhaps I'm wrong, haven't verified.
Otherwise LGTM (though, I didn't spot anything about allocatables in the
patch, am I just looking wrong or are they still unsupported)?
Jakub
Re: [Patch] Fortran: Support OpenMP's 'allocate' directive for stack vars
On 13.10.23 13:01, Jakub Jelinek wrote:
On Tue, Oct 10, 2023 at 06:46:35PM +0200, Tobias Burnus wrote:
+++ b/gcc/gimplify.cc
@@ -1400,23 +1400,53 @@ gimplify_bind_expr (tree *expr_p, gimple_seq *pre_p)
+ else if (errorcount
+ || (align == NULL_TREE
+ && alloc != NULL_TREE
+ && integer_onep (alloc)))
+DECL_ATTRIBUTES (t) = remove_attribute ("omp allocate",
+DECL_ATTRIBUTES (t));
Probably already preexisting, by I wonder how safe remove_attribute is.
Aren't attributes shared in some cases
(like __attribute__((attr1, attr2, attr3)) int a, b, c, d;)?
I think there should be no problem – new attributes get added as:
DECL_ATTRIBUTES (var) = tree_cons (get_identifier ("omp allocate"),
t, DECL_ATTRIBUTES (var));
Thus, attr = DECL_ATTRIBUTES (var) is not shared, even if
TREE_CHAIN (attr) might be shared.
Thus, as long as new attributes get added at the head of the chain,
there should be no issue. And "omp allocate" is added once per decl
and is therefore not shared - removing might create again a shared
tree, but any following 'tree_cons' will again unshare it.
I think in your case, there would be indeed a problem when doing:
'tree attr = remove_attr (...("attr2") ...)'
as this would remove "attr2" for 4 decls.
* * *
However, as 'omp allocate' is not used later on, I also do not need
to remove it.
=> Updated patch attached + interdiff for gimplify.cc attached.
Changes:
* Condition now the same as previously
* Keep 'omp allocate' also for DECL_VALUE_EXPR variable
* Add assert that we either have Fortran's expression the GOMP_FREE
location - or a DECL_VALUE_EXPR.
* Make use of the assertion by keeping the HAS_DECL_VALUE expr below;
this avoids adding an align/allocator == default check.
=> same code as old code, except for creating + using 'v' variable
and adding a clobber.
* * *
Otherwise LGTM (though, I didn't spot anything about allocatables in the
patch, am I just looking wrong or are they still unsupported)?
It's unsupported – albeit Chung-Lin has some patch for it. The code path
is completely different. It already starts by 'omp allocators' (+
legacy: 'omp allocate') being not declarative but executable and
associated with a Fortran 'allocate' statement and ...
Sorry for being slow - but I keep getting distracted by other tasks ...
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
diff -u b/gcc/gimplify.cc b/gcc/gimplify.cc
--- b/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -1400,13 +1400,10 @@
"region must specify an % clause", t);
/* Skip for omp_default_mem_alloc (= 1),
unless align is present. */
- else if (errorcount
- || (align == NULL_TREE
- && alloc != NULL_TREE
- && integer_onep (alloc)))
- DECL_ATTRIBUTES (t) = remove_attribute ("omp allocate",
- DECL_ATTRIBUTES (t));
- else
+ else if (!errorcount
+ && (align != NULL_TREE
+ || alloc == NULL_TREE
+ || !integer_onep (alloc)))
{
/* Fortran might already use a pointer type internally;
use that pointer except for type(C_ptr) and type(C_funptr);
@@ -1426,10 +1423,10 @@
tmp = build_pointer_type (type);
v = create_tmp_var (tmp, get_name (t));
DECL_IGNORED_P (v) = 0;
- tmp = remove_attribute ("omp allocate", DECL_ATTRIBUTES (t));
DECL_ATTRIBUTES (v)
= tree_cons (get_identifier ("omp allocate var"),
- build_tree_list (NULL_TREE, t), tmp);
+ build_tree_list (NULL_TREE, t),
+ DECL_ATTRIBUTES (t));
tmp = build_fold_indirect_ref (v);
TREE_THIS_NOTRAP (tmp) = 1;
SET_DECL_VALUE_EXPR (t, tmp);
@@ -1461,6 +1458,11 @@
tmp = fold_build2_loc (loc, MODIFY_EXPR, TREE_TYPE (v), v,
fold_convert (TREE_TYPE (v), tmp));
gcc_assert (BIND_EXPR_BODY (bind_expr) != NULL_TREE);
+ /* Ensure that either TREE_CHAIN (TREE_VALUE (attr) is set
+ and GOMP_FREE added here or that DECL_HAS_VALUE_EXPR_P (t)
+ is set, using in a condition much further below. */
+ gcc_assert (DECL_HAS_VALUE_EXPR_P (t)
+ || TREE_CHAIN (TREE_VALUE (attr)));
if (TREE_CHAIN (TREE_VALUE (attr)))
{
/* Fortran is special as it does not have properly nest
@@ -1631,14 +1633,15 @@
{
tree attr;
if (flag_openmp
+ && DECL_HAS_VALUE_EXPR_P (t)
&& TREE_USED (t)
&& ((attr = lookup_attribute ("omp allocate",
DECL_ATTRIBUTES (t))) != NULL_TREE)
&& TREE_CHAIN (TREE_VALUE (attr)) == NULL_TREE)
{
- /* For Fortran, the GOMP_free has already been added above. */
- tree v = (DECL_HAS_VALUE_EXPR_P (t)
-
Re: [PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]
On 10/11/23 12:39 PM, Harald Anlauf wrote: Dear All, the attached trivial patch fixes (= catches) a forgotten corner-case in the detection of a name conflict between an internal procedure and a local declaration for the case that the latter is a derived type. Another torture test by Gerhard... ;-) Used to ICE previously. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald This one is OK Harald. Thanks, Jerry
Re: [PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]
On 10/11/23 12:44 PM, Harald Anlauf wrote: Dear All, sorry for attaching the wrong patch - this time it is the correct one! Harald On 10/11/23 21:39, Harald Anlauf wrote: Dear All, the attached trivial patch fixes (= catches) a forgotten corner-case in the detection of a name conflict between an internal procedure and a local declaration for the case that the latter is a derived type. Another torture test by Gerhard... ;-) Used to ICE previously. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald This one is OK as well. Once I found the right patch on the right email. Regardless, both good to go. Thanks, Jerry
