Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

[varma datla via Fortran]

Hi, My name is Satyanarayana Varma. I am willing to contribute to the
project idea "Fortran – DO CONCURRENT". Please suggest some resources to me
so that I can learn your technologies. Could you please assign me some good
first issues for the starting.

Thank you,

Regards.
Satyanarayana Datla

Re: Support for WEAK attribute, part 2

[Rimvydas Jasinskas via Fortran]

Thank you Harald, for the feedback!

Attached is part2 patch for weak variables support.  I'll post part3
patch for module-wide attribute support separately.

Best regards,
Rimvydas
From fb1cf60d3fd7c6aa2d9787bb3af86f18e0178bf7 Mon Sep 17 00:00:00 2001
From: Rimvydas Jasinskas 
Date: Thu, 23 Feb 2023 12:55:28 +
Subject: Fortran: Add support for WEAK attribute for variables

 Add the rest of the weak-*.f90 testcases.

gcc/fortran/ChangeLog:

	* trans-decl.cc (gfc_finish_var_decl): Apply attribute.
	(generate_local_decl): Add diagnostic for dummy or local variables.

gcc/testsuite/ChangeLog:

	* gfortran.dg/weak-2.f90: New test.
	* gfortran.dg/weak-3.f90: New test.
	* gfortran.dg/weak-4.f90: New test.
	* gfortran.dg/weak-5.f90: New test.
	* gfortran.dg/weak-6.f90: New test.
	* gfortran.dg/weak-7.f90: New test.
	* gfortran.dg/weak-8.f90: New test.

Signed-off-by: Rimvydas Jasinskas 
---
 gcc/fortran/trans-decl.cc|  9 +
 gcc/testsuite/gfortran.dg/weak-2.f90 |  9 +
 gcc/testsuite/gfortran.dg/weak-3.f90 |  9 +
 gcc/testsuite/gfortran.dg/weak-4.f90 | 10 ++
 gcc/testsuite/gfortran.dg/weak-5.f90 | 15 +++
 gcc/testsuite/gfortran.dg/weak-6.f90 |  6 ++
 gcc/testsuite/gfortran.dg/weak-7.f90 | 13 +
 gcc/testsuite/gfortran.dg/weak-8.f90 |  9 +
 8 files changed, 80 insertions(+)
 create mode 100644 gcc/testsuite/gfortran.dg/weak-2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-4.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-5.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-6.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-7.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-8.f90

diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index ff64588b9a8..24a85cf6043 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -814,6 +814,10 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
   && (TREE_STATIC (decl) || DECL_EXTERNAL (decl)))
 set_decl_tls_model (decl, decl_default_tls_model (decl));
 
+  /* Mark weak variables.  */
+  if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+declare_weak (decl);
+
   gfc_finish_decl_attrs (decl, &sym->attr);
 }
 
@@ -5885,6 +5889,11 @@ generate_local_decl (gfc_symbol * sym)
   if (!sym->attr.dummy && !sym->ns->proc_name->attr.entry_master)
 	generate_dependency_declarations (sym);
 
+  if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+	gfc_error ("Symbol %qs at %L has the WEAK attribute but is a %s",
+		   sym->name, &sym->declared_at, sym->attr.dummy
+		   ? "dummy argument" : "local variable");
+
   if (sym->attr.referenced)
 	gfc_get_symbol_decl (sym);
 
diff --git a/gcc/testsuite/gfortran.dg/weak-2.f90 b/gcc/testsuite/gfortran.dg/weak-2.f90
new file mode 100644
index 000..0c948640c89
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/weak-2.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-require-weak "" }
+! { dg-skip-if "" { x86_64-*-mingw* } }
+! { dg-skip-if "" { nvptx-*-* } }
+! { dg-final { scan-assembler "weak\[^ \t\]*\[ \t\]_?impl" } }
+integer function impl()
+implicit none
+!GCC$ ATTRIBUTES weak :: impl
+end function
diff --git a/gcc/testsuite/gfortran.dg/weak-3.f90 b/gcc/testsuite/gfortran.dg/weak-3.f90
new file mode 100644
index 000..39ad299291b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/weak-3.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-require-weak "" }
+! { dg-skip-if "" { x86_64-*-mingw* } }
+! { dg-skip-if "" { nvptx-*-* } }
+! { dg-final { scan-assembler "weak\[^ \t\]*\[ \t\]_?bar__" } }
+integer function impl() bind(c,name='bar__')
+implicit none
+!GCC$ ATTRIBUTES weak :: impl
+end function
diff --git a/gcc/testsuite/gfortran.dg/weak-4.f90 b/gcc/testsuite/gfortran.dg/weak-4.f90
new file mode 100644
index 000..fef0233be8a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/weak-4.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! { dg-require-weak "" }
+! { dg-skip-if "" { x86_64-*-mingw* } }
+! { dg-skip-if "" { nvptx-*-* } }
+! { dg-final { scan-assembler "weak\[^ \t\]*\[ \t\]_?__foo_MOD_abc" } }
+module foo
+implicit none
+!GCC$ ATTRIBUTES weak :: abc
+real :: abc(7)
+end module
diff --git a/gcc/testsuite/gfortran.dg/weak-5.f90 b/gcc/testsuite/gfortran.dg/weak-5.f90
new file mode 100644
index 000..e48a8053570
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/weak-5.f90
@@ -0,0 +1,15 @@
+! { dg-do compile }
+! { dg-require-weak "" }
+! { dg-options "-Wall -Wextra" }
+module foo
+implicit none
+real :: a,b
+common /c/ a,b
+integer :: c
+! no error, common /c/ is not exported and variable 'c' has a mangled name
+!GCC$ ATTRIBUTES weak :: c
+contains
+ subroutine bar
+  c = 1
+ end subroutine
+end module
diff --git a/gcc/testsuite/gfortran.dg/weak-6.f90 b/gcc/testsuite/gfortran.dg/weak-6.f90
new file mode 100644
index 000..bcdf4df78a6
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/weak-6.f90
@@ -0,0 +1,6 @@
+! { dg-d

Support for module-wide attributes

[Rimvydas Jasinskas via Fortran]

Hello everyone,

this patch implements module-wide gcc directive support to apply
attributes to the whole module.  Patch closely follows how plain SAVE
statement is implemented with seen_save/gfc_save_all() by using
"mod_ext_attr" bitfield in a current namespace.

There are certain complications how WEAK attribute could be safely
applied to non local symbols, applying WEAK attribute requires to
delay this until build_function_decl() sets the final attr.access
field.

For a time being I opted out to explicitly reject setting the
NO_ARG_CHECK attribute for the whole module.  There should not be a
legitimate case to apply it for every dummy argument.

One DEPRECATED diagnostic (for deprecated parameter use case inside
the same module) did not carry out from the original
gfortran.dg/attr_deprecated.f90 testcase.  Not sure how to tackle it
yet, parsing order is a bit confusing.  Giving diagnostics for
deprecated symbols inside the whole module marked as deprecated seems
to be a bit excessive.  Only giving diagnostics for the actual use
cases of such marked module components would seem to be more
intuitive.  Also from the original testcase:
use m  ! { dg-warning "Using parameter 'parm' declared at .1. is deprecated" }
shouldn't diagnostic prefer to report "use" location instead of
declaration, since it is more important for the user?  The declaration
location could be additionally reported as dg-note using some helper
function that checks if the symbol is "imported at (1)" versus
"declared at (1)".

Regtested cleanly on x86_64-pc-linux-gnu.

Regards,
Rimvydas
From e5319c1733bca56be710c8cbce763fe459dfae73 Mon Sep 17 00:00:00 2001
From: Rimvydas Jasinskas 
Date: Thu, 23 Feb 2023 12:59:57 +
Subject: Fortran: Add support for module-wide attributes

 The WEAK attribute handling needs to be delayed after sym->attr.access is set.

gcc/fortran/ChangeLog:

	* decl.cc (gfc_match_gcc_attributes): Add diagnostic for NO_ARG_CHECK.
	* gfortran.h (gfc_apply_mod_ext_attr): New prototype.
	(gfc_namespace): Add mod_ext_attr bitfield.
	* resolve.cc (resolve_types): Use gfc_apply_mod_ext_attr().
	* symbol.cc (apply_mod_ext_attr): New procedure.
	(gfc_apply_mod_ext_attr): New procedure.
	* trans-decl.cc (build_function_decl): Handle module-wide WEAK
	attribute for public procedures.  Move local 'attr' copy down.
	(gfc_create_module_variable): Handle module-wide WEAK attribute for
	non-private variables.

gcc/testsuite/ChangeLog:

	* gfortran.dg/attr_deprecated-3.f90: New test.
	* gfortran.dg/attr_deprecated-4.f90: New test.
	* gfortran.dg/no_arg_check_4.f90: New test.
	* gfortran.dg/noinline-2.f90: New test.
	* gfortran.dg/noreturn-6.f90: New test.
	* gfortran.dg/weak-10.f90: New test.
	* gfortran.dg/weak-11.f90: New test.
	* gfortran.dg/weak-12.f90: New test.
	* gfortran.dg/weak-9.f90: New test.

Signed-off-by: Rimvydas Jasinskas 
---
 gcc/fortran/decl.cc   | 11 ++
 gcc/fortran/gfortran.h|  3 ++
 gcc/fortran/resolve.cc|  3 ++
 gcc/fortran/symbol.cc | 38 +++
 gcc/fortran/trans-decl.cc | 16 +++-
 .../gfortran.dg/attr_deprecated-3.f90 | 30 +++
 .../gfortran.dg/attr_deprecated-4.f90 | 24 
 gcc/testsuite/gfortran.dg/no_arg_check_4.f90  | 14 +++
 gcc/testsuite/gfortran.dg/noinline-2.f90  | 29 ++
 gcc/testsuite/gfortran.dg/noreturn-6.f90  | 10 +
 gcc/testsuite/gfortran.dg/weak-10.f90 | 17 +
 gcc/testsuite/gfortran.dg/weak-11.f90 | 17 +
 gcc/testsuite/gfortran.dg/weak-12.f90 | 18 +
 gcc/testsuite/gfortran.dg/weak-9.f90  | 17 +
 14 files changed, 245 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/attr_deprecated-3.f90
 create mode 100644 gcc/testsuite/gfortran.dg/attr_deprecated-4.f90
 create mode 100644 gcc/testsuite/gfortran.dg/no_arg_check_4.f90
 create mode 100644 gcc/testsuite/gfortran.dg/noinline-2.f90
 create mode 100644 gcc/testsuite/gfortran.dg/noreturn-6.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-10.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-11.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-12.f90
 create mode 100644 gcc/testsuite/gfortran.dg/weak-9.f90

diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index eec0314cf4c..9bc05f5acd8 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -11811,6 +11811,17 @@ gfc_match_gcc_attributes (void)
 
   sym->attr.ext_attr |= attr.ext_attr;
 
+  if (sym->attr.flavor == FL_MODULE)
+	{
+	  if (attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
+	{
+	  gfc_error ("The % attribute cannot be applied"
+			 " module-wide at %C");
+	  return MATCH_NO;
+	}
+	  gfc_current_ns->mod_ext_attr |= attr.ext_attr;
+	}
+
   if (gfc_match_eos () == MATCH_YES)
 	break;
 
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index fea2531

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

[Tobias Burnus]

Hi,

and welcome to the GCC / gfortran community.

On 23.02.23 14:15, varma datla via Fortran wrote:

I am willing to contribute to the project idea "Fortran – DO CONCURRENT".


I hope the following helps a bit – it is admittedly a bit chaotic, but I
try to write something cleaner later.

But to have something to think of and to startwith, it should be sufficient:

I think there are two parts to it: First, to add the changes of newer
Fortran to gfortran and then to actually use them to generate
concurrently running code. (Internally, gfortran currently handles 'do
concurrent' to run mostly like a normal loop – except that it annotates
the loops are independent. – Real parallelization would be useful, however.)

If you want to see examples, see do_concurrent_1.f90 to
do_concurrent_6.f90 in gfortran's testsuite, i.e.
gcc/testsuite/gfortran.dg/ in the GCC sources. That's at
https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/testsuite/gfortran.dg;hb=refs/heads/master
/ But it is best to download GCC yourself via Git as described at
https://gcc.gnu.org/git.html

I want to note that the DO CONCURRENT syntax also permits a mask
argument, like in 'do concurrent (i=1:5, j=1:5, (i/=j))' where the last
argument selects a subset.

For the Fortran standard, see https://gcc.gnu.org/wiki/GFortranStandards

Fortran 2018 (= 18-007r1) adds for locality specifiers: LOCAL,
LOCAL_INIT, SHARED and DEFAULT(NONE).

Fortran 202x alias 2023 adds 'reduce' as in 'do concurrent (i = 1, n)
reduce(+:a, b, c) reduce(max:d, e, f)'

I think the first step is to add parsing support for those new features,
i.e. store them, check for issues (diagnostic) and then fail with a
'sorry not yet implemented'.

The next step would be to implement LOCAL/LOCAL_INIT for running on the
host.

And then, finally, would be to translate into code which can then be run
concurrently. I was thinking of mapping it internally to OpenMP or
OpenACC, to be toggled via a commandline option like
-fdo-concurrent=.

* * *

I think the first step would be to download GCC and build it. Something
like "git clone" as described above, then "mkdir build" (some
directory); "cd build" and then "../configure --prefix=where-to-install"
followed by "make -j12" and "make install". The "-j12" runs 12 build
jobs in parallel. How much to use depends on your system.

You probably need to install some development versions of libraries such
as ISL, gmp, mpfr and mpc. If you don't have them readily, an option is
to run ./contrib/download_prerequisites to download those and build them
automatically alongside GCC.

So far for now. If you have questions, please ask. — And I will try to
write something more structured later.

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

-
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: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

[Damian Rouson]

I wonder if a relatively easy starting point would be enabling the
declaration of do concurrent construct variables:

do concurrent (integer :: i = 1:n)

It’s a minor convenience and less exciting than adding locality specifiers
but possibly a good first exercise.


Damian

On Thu, Feb 23, 2023 at 07:08 Tobias Burnus  wrote:

> Hi,
>
> and welcome to the GCC / gfortran community.
>
> On 23.02.23 14:15, varma datla via Fortran wrote:
> > I am willing to contribute to the project idea "Fortran – DO CONCURRENT".
>
> I hope the following helps a bit – it is admittedly a bit chaotic, but I
> try to write something cleaner later.
>
> But to have something to think of and to startwith, it should be
> sufficient:
>
> I think there are two parts to it: First, to add the changes of newer
> Fortran to gfortran and then to actually use them to generate
> concurrently running code. (Internally, gfortran currently handles 'do
> concurrent' to run mostly like a normal loop – except that it annotates
> the loops are independent. – Real parallelization would be useful,
> however.)
>
> If you want to see examples, see do_concurrent_1.f90 to
> do_concurrent_6.f90 in gfortran's testsuite, i.e.
> gcc/testsuite/gfortran.dg/ in the GCC sources. That's at
>
> https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=gcc/testsuite/gfortran.dg;hb=refs/heads/master
> / But it is best to download GCC yourself via Git as described at
> https://gcc.gnu.org/git.html
>
> I want to note that the DO CONCURRENT syntax also permits a mask
> argument, like in 'do concurrent (i=1:5, j=1:5, (i/=j))' where the last
> argument selects a subset.
>
> For the Fortran standard, see https://gcc.gnu.org/wiki/GFortranStandards
>
> Fortran 2018 (= 18-007r1) adds for locality specifiers: LOCAL,
> LOCAL_INIT, SHARED and DEFAULT(NONE).
>
> Fortran 202x alias 2023 adds 'reduce' as in 'do concurrent (i = 1, n)
> reduce(+:a, b, c) reduce(max:d, e, f)'
>
> I think the first step is to add parsing support for those new features,
> i.e. store them, check for issues (diagnostic) and then fail with a
> 'sorry not yet implemented'.
>
> The next step would be to implement LOCAL/LOCAL_INIT for running on the
> host.
>
> And then, finally, would be to translate into code which can then be run
> concurrently. I was thinking of mapping it internally to OpenMP or
> OpenACC, to be toggled via a commandline option like
> -fdo-concurrent=.
>
> * * *
>
> I think the first step would be to download GCC and build it. Something
> like "git clone" as described above, then "mkdir build" (some
> directory); "cd build" and then "../configure --prefix=where-to-install"
> followed by "make -j12" and "make install". The "-j12" runs 12 build
> jobs in parallel. How much to use depends on your system.
>
> You probably need to install some development versions of libraries such
> as ISL, gmp, mpfr and mpc. If you don't have them readily, an option is
> to run ./contrib/download_prerequisites to download those and build them
> automatically alongside GCC.
>
> So far for now. If you have questions, please ask. — And I will try to
> write something more structured later.
>
> Tobias
>
> --
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 Münch
> en;
> Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung,
> Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB
> 106955
>
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
> 80634 Münch
> en;
> Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung,
> Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB
> 106955
>

Re: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

[Tobias Burnus]

(I have now also left out the gcc* mailing list, leaving only
fortran@gcc.gnu.org in.)

On 23.02.23 16:24, Damian Rouson wrote:


I wonder if a relatively easy starting point would be enabling the
declaration of do concurrent construct variables:

do concurrent (integer :: i = 1:n)

It’s a minor convenience and less exciting than adding locality
specifiers but possibly a good first exercise.


I concur that this is a useful Fortran 2018 feature. But this creates a
new scope which is also not that straight forward. Thus, maybe rather
something for a third instead of for the first exercise :-)

But in any case, another F2018 omission – and good that you spotted the
omission.

* * *

Regarding building GCC: If you build as mentioned in my previous email,
GCC is bootstrapped. That is: It is build first with the system compiler
(likely some older GCC), then the just build compiler is used to build
GCC again (without debugging symbols), then that one is used to build
GCC a third time (with debugging symbols) — and then there is a check
whether the generated in Stage 3 with debugging symbols stripped is
identical to the one in Stage 2.

If you develop, a faster way is to build with: --disable-bootstrap
--disable-multilib --disable-libstdcxx-pch

* The first one disables the three-stage build process and builds only
with the system compiler. (Caveat: This one might have different
warnings. Thus, when a patch is ready, a bootstrap build is required to
avoid surprises with warnings treated as errors.)

* The second one disables 32bit support, which is usually build
alongside 64bit support on Linux.

* PCH are C++ pre-compiled headers. Those take some time to build and
also slows building down.

Running the GCC testsuite:

"make check-fortran -j12" in the main build directory tests everything
Fortran related (libgomp/testsuite/ and gcc/testsuite/*fortran*/.) – To
check for a specific testcase in the latter, do "cd gcc" in the build
directory and run 'make check-fortran RUNTESTFLAGS="dg.exp=myTest*.f90"'
where dg.exp is the file in the gfortran.dg/ directory and myTest*.f90
matches the file name.

What is done with the tests is determined by '{ dg-... }' in the comment
lines, in particular 'dg-do run/compile' tells whether it is a run-time
or compile-time check. And 'dg-error'/'dg-warning' check for the
presence of diagnostic lines.

* * *

I think I stop here. — If you have questions or something is unclear or
does not work, please tell.

Tobias

PS: For the greater picture, in particular Nvidia did some experiments
with running do concurrent really concurrently (with offloading to their
accelerators). See for instance:
https://developer.nvidia.com/blog/using-fortran-standard-parallel-programming-for-gpu-acceleration/
and
https://developer.nvidia.com/blog/accelerating-fortran-do-concurrent-with-gpus-and-the-nvidia-hpc-sdk/

That's unsurprisingly a bit Nvidia centric, but it should give an idea
how concurrency handling could look like.

-
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: Willing to contribute to the project Idea "Fortran – DO CONCURRENT"

[Steve Kargl via Fortran]

On Thu, Feb 23, 2023 at 07:24:26AM -0800, Damian Rouson wrote:
> I wonder if a relatively easy starting point would be enabling the
> declaration of do concurrent construct variables:
> 
> do concurrent (integer :: i = 1:n)
> 
> It’s a minor convenience and less exciting than adding locality specifiers
> but possibly a good first exercise.
> 
> 
> Damian

I've already implemented 95% of the above.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255

Unfortunately, the last 5% will take me too much time,
which I don't have at the moment.  Problems arise from
the parsing of an iterator is shared by do current, forall,
implied-do, and good old do-loops.  For the first 3, 'i' is
a control variable and is a statement entity (i.e., in the
namespace of construct).  To do a type spec in one of these
cleanly, it would be prudent to either define a namespace
for the construct or to use a shadow variable.  The shadow 
variablei, which I was leaning towards, would replace the
above with something like

  do concurrent (integer :: _i = 1:n)

'_i' cannot conflict 'i', but this requires walking the 
execution block of the construct and replacing 'i' with '_i'.

Perhaps, starting with the patch in PR96255 would be gentle
intro to gfortran hacking.
-- 
Steve

Re: [Patch] Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

[Tobias Burnus]

Minor change to previous patch – it did not affect the mainline build
but it makes more sense this way and on OG12, i.e. with mapping
allocatable components (patch posted last year in Q1 during Stage 4),
it gave an ICE without this change as one '*' wasn't stripped.

--- b/gcc/fortran/trans-openmp.cc
+++ b/gcc/fortran/trans-openmp.cc
@@ -3439,5 +3439,5 @@
  && n->sym->ts.deferred)
{
- if (!present && !DECL_P (decl))
+ if (!DECL_P (decl))
{
  gcc_assert (TREE_CODE (decl) == INDIRECT_REF);

Otherwise, the same written before applies, see below.

(Side note: this patch has been committed to OG12 as 
http://gcc.gnu.org/g:55a18d47442 )

On 21.02.23 12:57, Tobias Burnus wrote:

This patch moves some generic code for Fortran out of gimplify.cc
to trans-openmp.cc and fixes several issues related to mapping.

Tested with nvptx offloading.
OK for mainline?

Tobias

Caveats:

Besides the issues shown in the comment-out code, there remains also an
issue with implicit mapping - at least for deferred-length strings,
but I wouldn't be surprised if - at least depending on the used
'defaultmap' value (e.g. 'alloc') - there are also issues with array
descriptors.

Note:

Regarding the declare target check for mapping: Without declare
target, my assumption is that the hidden length variable will
get implicitly mapped if needed. Independent of deferred-length
or not, there is probably an issue with 'defaultmap(none)' and
the hidden variable. - In any case, I prefer to defer all those
issues to later (by having them captured in one/several PR).


Tobias

PS: This patch is a follow up to
  [Patch] Fortran/OpenMP: Fix DT struct-component with 'alloc' and
array descr
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/604887.html
which fixed part of the problems. But as discussed on IRC, it did
treat 'alloc'
as special and missed some other map types. - In addition, this patch
has a
much extended test coverage and fixes some more issues found that way.

-
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
Fortran/OpenMP: Fix mapping of array descriptors and deferred-length strings

Previously, array descriptors might have been mapped as 'alloc'
instead of 'to' for 'alloc', not updating the array bounds. The
'alloc' could also appear for 'data exit', failing with a libgomp
assert. In some cases, either array descriptors or deferred-length
string's length variable was not mapped. And, finally, some offset
calculations with array-sections mappings went wrong.

The testcases contain some comment-out tests which require follow-up
work and for which PR exist. Those mostly relate to deferred-length
strings which have several issues beyong OpenMP support.

gcc/fortran/ChangeLog:

	* trans-decl.cc (gfc_get_symbol_decl): Add attributes
	such as 'declare target' also to hidden artificial
	variable for deferred-length character variables.
	* trans-openmp.cc (gfc_trans_omp_array_section,
	gfc_trans_omp_clauses, gfc_trans_omp_target_exit_data):
	Improve mapping of array descriptors and deferred-length
	string variables.

gcc/ChangeLog:

	* gimplify.cc (gimplify_scan_omp_clauses): Remove Fortran
	special case.

libgomp/ChangeLog:

	* testsuite/libgomp.fortran/target-enter-data-3.f90: Uncomment
	'target exit data'.
	* testsuite/libgomp.fortran/target-enter-data-4.f90: New test.
	* testsuite/libgomp.fortran/target-enter-data-5.f90: New test.
	* testsuite/libgomp.fortran/target-enter-data-6.f90: New test.
	* testsuite/libgomp.fortran/target-enter-data-7.f90: New test.

 gcc/fortran/trans-decl.cc  |   2 +
 gcc/fortran/trans-openmp.cc| 323 
 gcc/gimplify.cc|  42 +-
 .../libgomp.fortran/target-enter-data-3.f90|   2 +-
 .../libgomp.fortran/target-enter-data-4.f90| 540 +
 .../libgomp.fortran/target-enter-data-5.f90| 540 +
 .../libgomp.fortran/target-enter-data-6.f90| 392 +++
 .../libgomp.fortran/target-enter-data-7.f90|  78 +++
 8 files changed, 1783 insertions(+), 136 deletions(-)

diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index ff64588..c46ffc1 100644
--- a/gcc/fortran/trans-decl.cc
+++ b/gcc/fortran/trans-decl.cc
@@ -1820,6 +1820,8 @@ gfc_get_symbol_decl (gfc_symbol * sym)
   /* Add attributes to variables.  Functions are handled elsewhere.  */
   attributes = add_attributes_to_decl (sym->attr, NULL_TREE);
   decl_attributes (&decl, attributes, 0);
+  if (sym->ts.deferred)
+decl_attributes (&length, attributes, 0);
 
   /* Symbols from modules should have their assembler names mangled.
  This is 

GCC has been accepted as a GSoC mentoring org

[Martin Jambor]

Hello,

I'm happy to announce that GCC has been accepted as a mentoring
organization in Google Summer of Code 2023!

The program is now in a phase that is called

  "Potential GSoC contributors discuss application ideas with mentoring
   organizations"

and so let's do just that.  Contributors will then be applying in
between March 20 and April 4.

So if any of you is still thinking of mentoring a project, now is the
right time to propose it (see
https://gcc.gnu.org/pipermail/gcc/2023-January/240495.html).

Thanks!

Martin

Re: Support for WEAK attribute, part 2

[Harald Anlauf via Fortran]

Hi Rimvydas,

> Attached is part2 patch for weak variables support.

the patch is mostly fine, but there is a minor style issue:

+  if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+   gfc_error ("Symbol %qs at %L has the WEAK attribute but is a %s",
+  sym->name, &sym->declared_at, sym->attr.dummy
+  ? "dummy argument" : "local variable");
+

It is my understanding that this is not translation-friendly.
Please use separate error texts for either case instead.

Do we need to really have that many separate files for all
the tests?  Note that each separate file contributes to the
time developers wait on regtesting to complete.  Some of the
files essentially test only minor variations, like weak-2.f90
and weak-3.f90.

What is the purpose of testcase weak-5.f90?  It's valid
Fortran, the common block /c/ shows in the assembler and
does not interfere with the module variable c.

If you are interested in the interaction of name mangling
and weak declarations, isn't that already done in weak-4.f90?

Also, is it possible to combine weak-6.f90 and weak-7.f90?

Finally, please do not forget to CC patches to gcc-patches@
so that others can see them.

Thanks,
Harald

Re: Support for WEAK attribute, part 2

[Rimvydas Jasinskas via Fortran]

On Thu, Feb 23, 2023 at 10:53 PM Harald Anlauf  wrote:
> the patch is mostly fine, but there is a minor style issue:
>
> +  if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
> +   gfc_error ("Symbol %qs at %L has the WEAK attribute but is a %s",
> +  sym->name, &sym->declared_at, sym->attr.dummy
> +  ? "dummy argument" : "local variable");
> +
>
> It is my understanding that this is not translation-friendly.
> Please use separate error texts for either case instead.
Interesting, I was under the impression this was fixed with OO-inlines
around the *.c rename.  In any case, adjusted in v2 to use:
+  if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+{
+  if (sym->attr.dummy)
+gfc_error ("Symbol %qs at %L has the WEAK attribute but is a "
+   "dummy argument", sym->name, &sym->declared_at);
+  else
+gfc_error ("Symbol %qs at %L has the WEAK attribute but is a "
+   "local variable", sym->name, &sym->declared_at);
+}

> Do we need to really have that many separate files for all
> the tests?  Note that each separate file contributes to the
> time developers wait on regtesting to complete.  Some of the
> files essentially test only minor variations, like weak-2.f90
> and weak-3.f90.
These testcases are dg-compile and do not go through the "-O0 -O1 -O2
-O3 -Os" options like dg-run.  Combining the testcases does not reduce
gfortran.sum a lot:
-PASS: gfortran.dg/weak-2.f90   -O   scan-assembler weak[^ \t]*[ \t]_?impl
-PASS: gfortran.dg/weak-2.f90   -O  (test for excess errors)
-PASS: gfortran.dg/weak-3.f90   -O   scan-assembler weak[^ \t]*[ \t]_?bar__
-PASS: gfortran.dg/weak-3.f90   -O  (test for excess errors)
-PASS: gfortran.dg/weak-4.f90   -O   scan-assembler weak[^ \t]*[
\t]_?__foo_MOD_abc
-PASS: gfortran.dg/weak-4.f90   -O  (test for excess errors)
-PASS: gfortran.dg/weak-5.f90   -O  (test for excess errors)
-PASS: gfortran.dg/weak-6.f90   -O   (test for errors, line 3)
-PASS: gfortran.dg/weak-6.f90   -O  (test for excess errors)
-PASS: gfortran.dg/weak-7.f90   -O   (test for errors, line 10)
-PASS: gfortran.dg/weak-7.f90   -O   (test for errors, line 6)
-PASS: gfortran.dg/weak-7.f90   -O  (test for excess errors)
-PASS: gfortran.dg/weak-8.f90   -O   (test for errors, line 3)
-PASS: gfortran.dg/weak-8.f90   -O   (test for errors, line 7)
-PASS: gfortran.dg/weak-8.f90   -O  (test for excess errors)
+PASS: gfortran.dg/weak-2.f90   -O   scan-assembler weak[^ \t]*[
\t]_?__foo_MOD_abc
+PASS: gfortran.dg/weak-2.f90   -O   scan-assembler weak[^ \t]*[ \t]_?bar__
+PASS: gfortran.dg/weak-2.f90   -O   scan-assembler weak[^ \t]*[ \t]_?impl1
+PASS: gfortran.dg/weak-2.f90   -O  (test for excess errors)
+PASS: gfortran.dg/weak-3.f90   -O   (test for errors, line 14)
+PASS: gfortran.dg/weak-3.f90   -O   (test for errors, line 18)
+PASS: gfortran.dg/weak-3.f90   -O   (test for errors, line 24)
+PASS: gfortran.dg/weak-3.f90   -O   (test for errors, line 28)
+PASS: gfortran.dg/weak-3.f90   -O   (test for errors, line 5)
+PASS: gfortran.dg/weak-3.f90   -O  (test for excess errors)

Only benefit is a bit less gfortran/f951 binaries invocations at
expense of potentially introducing issues in what was intended to be
tested.  There exists a partial(intentionally or not) sequential
file-scope namespace (like in C) how gfortran parses different units
in the same file.  Swapping unit order in the file can affect not only
code generation but diagnostic counts reported.  I tend to avoid
having more than one unit per source to avoid dealing with
"borrowing".  However with part3 now implemented after debugging, I
guess, samples could be combined to "accepts" + "rejects" two
testcases,  Done in v2.

> What is the purpose of testcase weak-5.f90?  It's valid
> Fortran, the common block /c/ shows in the assembler and
> does not interfere with the module variable c.
Removed.  Issue is not directly related to only the WEAK attributes.
Will be addressed in the future.

> Finally, please do not forget to CC patches to gcc-patches@
> so that others can see them.
Out of curiosity, what is the purpose of CC patches to gcc-patches
too?  Attachments are even available in web mailing list too, like in:
https://gcc.gnu.org/pipermail/fortran/2023-February/058953.html

Regards,
Rimvydas
From 5b83226c714b17780334b5bad9b17c2266af8232 Mon Sep 17 00:00:00 2001
From: Rimvydas Jasinskas 
Date: Fri, 24 Feb 2023 04:41:00 +
Subject: Fortran: Add support for WEAK attribute for variables

 Add the rest of the weak-*.f90 testcases.

gcc/fortran/ChangeLog:

	* trans-decl.cc (gfc_finish_var_decl): Apply attribute.
	(generate_local_decl): Add diagnostic for dummy and local variables.

gcc/testsuite/ChangeLog:

	* gfortran.dg/weak-2.f90: New test.
	* gfortran.dg/weak-3.f90: New test.

Signed-off-by: Rimvydas Jasinskas 
---
 gcc/fortran/trans-decl.cc| 14 +
 gcc/testsuite/gfortran.dg/weak-2.f90 | 26 
 gcc/testsuite/gfortran.dg/weak

Re: Support for NOINLINE attribute

[Bernhard Reutner-Fischer via Fortran]

Hi Rimvydas!

On Sat, 18 Feb 2023 21:35:47 +0100
Bernhard Reutner-Fischer  wrote:

> On Fri, 10 Feb 2023 07:42:47 +0200
> Rimvydas Jasinskas via Fortran  wrote:
> 
> > * decl.cc: Add EXT_ATTR_NOINLINE, EXT_ATTR_NORETURN, EXT_ATTR_WEAK.
> > * gfortran.h (ext_attr_id_t): Ditto.  
> 
> We had that discussion recently here..
> Which of these are required to be recorded to the module and why,
> exactly? Please elaborate.
> 
> thanks,

The aforementioned discussion was here:
https://gcc.gnu.org/pipermail/fortran/2022-November/058542.html

So, again, please elaborate why you need to store each of NOINLINE,
NORETURN, WEAK in the module?

thanks